DUV32CAS00004-19980414 DIGITAL UNIX V3.2C Aggregate ECO Summary
Modification Date: 15-MAY-1998
Modification Type: Reload tar file to Internet
Copyright (c) DIGITAL Equipment Corporation 1998. All rights reserved.
PRODUCT: DIGITAL UNIX [R] 3.2C
SOURCE: DIGITAL Equipment Corporation
ECO INFORMATION:
ECO Name: DUV32CAS00004-19980414
ECO Kit Approximate Size: 42MB
Kit Applies To: DIGITAL UNIX 3.2C
ECO KIT SUMMARY:
An update ECO kit exists for DIGITAL UNIX 3.2C. This is the aggregate,
setld-based, patch kit for DIGITAL UNIX 3.2C. 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 patch Kit:
DUV32CAS00003-19970902 ! Previous Aggregate Patch Kit
OSF350-046
OSF350-047
OSF350-048
OSF350-093
OSF350-112
OSF350-160
OSF350-210
OSF350-211
OSF350-214
OSF350-275
OSF350x-021
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.
===============================================================================
- Root logouts are not being audited when auditing of logouts was enabled.
- Calls to setsysinfo(SSI_ULIMIT) were not restricted to superuser (root).
PROBLEM: (Patch ID: OSF350-004) (HPXQ62083)
********
Root logouts weren't being audited when auditing of logouts was enabled.
To reproduce this problem:
Use audit_setup to enable auditing of logouts.
Use audit_tool to examine the audit log, root logouts don't appear.
PROBLEM: (Patch ID: OSF350-004)
********
Calls to setsysinfo(SSI_ULIMIT) weren't restricted to superuser (root).
FILE(s):
/usr/sys/BINARY/sys_sysinfo.o subset OSFBIN350
CHECKSUM: 12739 13 RCS: 1.1.48.2 (sys_sysinfo.c,v)
===============================================================================
cmptun instruction can return TRUE when no NaN is present.
PROBLEM: (Patch ID: OSF350-010) (QAR 36500,CLD USG-02301)
********
The cmptun instruction returns TRUE for cases using infinities or denormals,
even with no NaN present. Mostly affects Freeport Express.
FILE(s):
/usr/sys/BINARY/fp_result.o subset OSFHWBIN350
CHECKSUM: 64860 17 RCS: 1.1.34.2 (fp_result.c)
===============================================================================
chmod -R will cause files which are targets of symbolic links to receive
incorrect permissions.
PROBLEM: (Patch ID: OSF350-015) (CLD TKTB77046)
********
chmod -R recursively changes the access modes correctly for directly referenced
files and incorrectly on files which are targets of symbolic links files.
Files which are targets of symbolic links have their access modes changed first
to 777 followed immediately by the chmod command line permission parameters.
FILE(s):
/sbin/chmod subset OSFBASE350
CHECKSUM: 61276 120 RCS: 4.2.23.2 (chmod.c)
/usr/bin/chmod subset OSFBASE350
CHECKSUM: 55732 24 RCS: 4.2.23.2 (chmod.c)
===============================================================================
System panics with the message: vm_object_free: res count > 1
PROBLEM: (Patch ID: OSF350-017) (evt101287 qar 35023)
********
The system panics with the following console message:
vm_object_free: res count > 1
A representative stack trace follows:
0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":698]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355]
5 panic("vm_object_free: res count > 1")
["../../../../src/kernel/bsd/subr_prf.c":719]
6 vm_object_free() ["../../../../src/kernel/vm/vm_object.c":270]
7 u_anon_oop_deallocate() ["../../../../src/kernel/vm/u_mape_anon.c":2641]
8 vm_map_entry_delete() ["../../../../src/kernel/vm/vm_map.c":1189]
9 u_map_delete() ["../../../../src/kernel/vm/vm_umap.c":1134]
10 u_map_deallocate() ["../../../../src/kernel/vm/vm_umap.c":364]
11 vm_map_deallocate() ["../../../../src/kernel/vm/vm_map.c":647]
12 task_deallocate() ["../../../../src/kernel/kern/task.c":427]
13 waitf() ["../../../../src/kernel/bsd/kern_exit.c":1564]
14 wait4() ["../../../../src/kernel/bsd/kern_exit.c":1287]
15 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":515]
16 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1086]
FILE(s):
/usr/sys/BINARY/vm_object.o subset OSFBIN350
CHECKSUM: 63893 9 RCS: 4.2.28.2 (vm_object.c)
===============================================================================
YACC fails with a Memory fault when used on large grammar file.
PROBLEM: (Patch ID: OSF350-018) (Case ID: QAR 32853)
********
YACC fails with a Segmentation fault when used on a large grammar file.
example:
$ yacc bigfile.y
Segmentation fault (core dumped)
FILE(s):
/usr/ccs/bin/yacc subset OSFPGMR350
CHECKSUM: 56538 72 RCS: 4.2.12.2 (y1.c)
===============================================================================
- snmp_pe core dumps when receiving unusual SNMP packets
- snmp_pe does not support the "no_auth_trap" directive in snmp_pe.conf.
- When running the snmpCollect daemon of Polycenter Netview 4.1, but could
occur when any random SNMP application formats packets unusually (not
necessarily improperly).
PROBLEM: (Patch ID: OSF350-019) (Case ID: QAR 33027)
********
snmp_pe reads configuration information from snmpd.conf. One of the directives
that may be contained in it is "no_auth_trap". When active, snmp_pe should NOT
send an authenticationFailure trap when it receives an SNMP request containing
an unknown community name.
The bug is that it DOES send the trap even when no_auth_trap is active.
PROBLEM: (Patch ID: OSF350-019) (No problem reports yet)
********
This bug was found during FT of Polycenter Netview V4.1, it has not been reported
by a customer yet. But the bug exists in all released versions of snmp_pe.
It is triggered by running the snmpCollect daemon of PNV 4.1, but could
conceivably occur when any random SNMP application formats packets unusually
(not necessarily improperly).
A characteristic stack trace:
(decladebug) where
>0 0x12001f0a8 in ilv_decode_obj_id_cpt() ../../../../../src/usr/sbin/snmp_pe/m
cc_asn1_objid.c:206
#1 0x12001ef60 in ilv_decode_object_id() ../../../../../src/usr/sbin/snmp_pe/mc
c_asn1_objid.c:133
#2 0x12001c66c in mcc_asn_get_ref() ../../../../../src/usr/sbin/snmp_pe/mcc_asn
1.c:1522
#3 0x12002270c in asn1_to_avl() ../../../../../src/usr/sbin/snmp_pe/snmp_lib.c:
2268
#4 0x120033d00 in netio_deserialize_pdu() ../../../../../src/usr/sbin/snmp_pe/s
nmppe_netio.c:651
#5 0x120025c28 in casend_get_msg() ../../../../../src/usr/sbin/snmp_pe/snmppe_c
asend.c:582
#6 0x12002e338 in main() ../../../../../src/usr/sbin/snmp_pe/snmppe_main.c:643
(decladebug) p p_Buf
Symbol p_Buf undefined.
Error: no value for p_Buf
(decladebug) up
>0 0x12001ef60 in ilv_decode_object_id() ../../../../../src/usr/sbin/snmp_pe/mc
c_asn1_objid.c:133
(Cannot find source file ../../../../../src/usr/sbin/snmp_pe/mcc_asn1_objid.c)
(decladebug) down
>0 0x12001f0a8 in ilv_decode_obj_id_cpt() ../../../../../src/usr/sbin/snmp_pe/m
cc_asn1_objid.c:206
(Cannot find source file ../../../../../src/usr/sbin/snmp_pe/mcc_asn1_objid.c)
(decladebug)
And in syslog:
Jun 26 09:29:43 shipit snmp_pe[20187]: M004 - snmp_pe (V1.10) initialization com
plete
Jun 26 09:38:25 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:38:29 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:38:37 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:38:53 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:38:57 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:39:05 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52878850), moss(-1), PDU ignored
Jun 26 09:39:21 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52875138), moss(-1), PDU ignored
Jun 26 09:39:25 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
.23.176.10, size = 484 (dec), mcc(52875138), moss(-1), PDU ignored
Jun 26 09:39:33 shipit snmp_pe[20187]: M052 - ASN.1 varbindlist parse failed on
PDU from 16
FILE(s):
/usr/sbin/snmp_pe subset OSFCOMAGENT350
CHECKSUM: 30797 336 RCS: mcc_asn1.c 1.1.10.2
RCS: snmppe_init.c 1.1.10.2
===============================================================================
PXG Family 2D Graphics Card Panic Correction:
The system panics during the initialization of the X server (which usually
occurs at the end of system startup when xdm is started).
PROBLEM: (Patch ID: OSF350-034) (HPXQ86C85,HPXQ87A4A,HPXQ85059)
********
On any Digital UNIX V3.2C system with a PXG-family graphics card, the system
panics during the initialization of the X server (which usually occurs at the
end of system startup when xdm is started).
Here is a sample stack trace:
0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1735]
1 panic() ["../../../../src/kernel/bsd/subr_prf.c":757]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":12139]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
4 bzero() ["../../../../src/kernel/arch/alpha/fastcopy.s":879]
5 pq_ioctl() ["../../../../src/kernel/io/dec/ws/pq.c":480]
6 wsioctl() ["../../../../src/kernel/io/dec/ws/ws_device.c":1461]
7 sccioctl() ["../../../../src/kernel/io/dec/tc/scc.c":2329]
8 cnioctl() ["../../../../src/kernel/arch/alpha/hal/cons_sw.c":204]
9 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":1974]
10 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1109]
11 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":465]
12 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":344]
13 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
14 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
The PXG-family consists of the following graphics options:
PMAG-DA PXG
PMAG-FA PXG Turbo
PMAG-EA PXG+
PMAGB-F PXG Turbo+
The PXG family of graphics options can be used with Digital UNIX V3.2C for
displaying 2D graphics only. Support for the PXG family has been retired in
Open3D V3.0 which runs on Digital UNIX V3.2C. Earlier versions of Open3D which
support the PXG family are not supported on Digital UNIX V3.2C.
FILE(s):
/usr/sys/data/steal_mem.c subset OSFHWBINCOM350
CHECKSUM: 26375 12 RCS: 1.1.27.2 (steal_mem.c)
===============================================================================
Using high-speed modems with LAT: application may fail because tty speed
is set to 0.
PROBLEM: (Patch ID: OSF350-039) (CLD HPAQ6396E,SPR HPAQ56EF8)
********
During a LAT session on a Digital UNIX system, using a high-speed modem
connected to a LAT server, some applications may fail to execute correctly
because the LAT subsystem has set the tty speed (as reported by stty) to 0.
This patch changes this behavior, so any attempt to set the speed higher
than 38400 bps results in the speed not being changed. stty should report
9600 as the tty speed.
FILE(s):
/usr/sys/BINARY/sxsig.o subset OSFBIN350
CHECKSUM: 54740 5 RCS: 1.1.13.2 (sxsig.c)
===============================================================================
An application that opens a LAT tty only once, should be allowed to issue writes
before the connection is fully established.
PROBLEM: (Patch ID: OSF350-040) (CLD MGO101472)
********
When an application opens a LAT tty with the O_NDELAY flag set, and the tty is
not closed immediately, data which the application has queued to this tty
(before the LAT connection has been fully established) will never get sent
unless there is also data to be sent from the remote side of the LAT connection.
FILE(s):
/usr/sys/BINARY/sxses.o subset OSFBIN350
CHECKSUM: 60783 6 RCS: 1.1.17.2 (sxses.c)
===============================================================================
Any user can cause a system panic by doing a read or ioctl on /dev/streams/dlpi
(i.e. the command "file /dev/streams/dlpi").
PROBLEM: (Patch ID: OSF350-042) (CLD HPXQ85E5C)
********
Any user can cause a system panic by doing a read or ioctl on /dev/streams/dlpi
(i.e. the command "file /dev/streams/dlpi").
FILE(s):
/usr/sys/BINARY/dlioctl.o subset OSFBIN350
CHECKSUM: 33106 5 RCS: 1.1.8.2 (dlioctl.c)
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (Patch ID: OSF350-048) (QAR-37084)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/dev/MAKEDEV subset OSFHWBASE350
CHECKSUM: 24943 31
===============================================================================
LSM rootdg Configuration Correction:
Fixes a problem that only occurs when the configuration database in the rootdg
diskgroup has records that will not fit in 512 sectors.
PROBLEM: ( MCPM8935A QAR 36456 ) ( Patch ID: OSF350-053 )
********
The problem will be seen if root/swap encapsulation or mirroring fails and the
rootdg diskgroup has been tuned to have a privlen greater than 512 sectors. The
problem only occurs when the configuration database in the rootdg diskgroup has
records that will not fit in 512 sectors. Hence only large LSM configuration
will see this problem.
The messages on the console during the encapsulation will show
"volassist: No more space in disk group configuration"
FILE(s):
/sbin/vol-reconfig subset OSFLSMBASE350
CHECKSUM: 50954 13 RCS: vol-reconfig.sh Revision: 1.1.13.2
===============================================================================
KSPSA driver panics with a "simple lock timout" message. This can happen in ASE
environments that have intermittent SCSI bus problems.
PROBLEM: ( QAR 37426 ) ( Patch ID: OSF350-057 )
********
KSPSA driver panics with a "simple lock timout" message. This can happen in ASE
environments that have intermittent SCSI bus problems.
FILE(s):
/usr/sys/BINARY/simport_htm.o subset OSFHWBIN350
CHECKSUM: 46408 25 RCS: simport_htm.c Revision: 1.1.35.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM 1: (Patch ID: OSF350-061) (Case ID: SSRT0329U, USG-01683)
**********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/bin/rdist subset OSFINET350
CHECKSUM: 22963 88 RCS: 4.2.21.2 (server.c)
===============================================================================
The system can panic when a disk is in a RAID set and is mislabelled.
PROBLEM: (Patch ID: OSF350-066) (HPAQ917D5)
********
The system can panic when a disk is in a RAID set and is mislabelled.
The system will panic with a stack trace similar to:
> 0 boot
1 panic
2 advfs_sad
3 bs_cow_pg
4 bs_cow
The error log will contain messages similar to:
advfs I/O error: setId 0x2fc0af89.00086de0.2.8051
tag 0x0000137d.8006u page 336
vd 1 blk 4110448 blkCnt 32
write error = 28
The disk being complained about is in a RAID set, and is disklabeled as a rz
disk and not an re disk.
The thing to note about the message is that the block number (4110448 in the
example) is very close to the end of the disk.
This panic is caused by the RAID controller appropriating some blocks at the
end of the disk for its own use. Advfs, however, thinks it can write the
entire disk because of the incorrect disklabel. The panic happens because
the RAID controller returns EIO when Advfs tries to write in the reserved
area.
This is a user error caused by incorrect labelling of the disk. This patch
causes mount_advfs fail to mount the domain read-write and issue an error
message rather than have the system panic later.
FILE(s):
/sbin/mount_advfs subset OSFADVFS350
CHECKSUM: 63721 216 RCS: 1.1.17.2 (mount_advfs.c)
===============================================================================
When illegal user arguments are passed to the semop() system call, such that
exactly none of the requested operations work, the system call code continues
in a path that corrupts memory by depositing a PID number in areas beyond
the semaphore structures allocated memory. When this occurs, the 16-byte
elements in kmembuckets[0] are the target of the corruption.
PROBLEM 1: (Patch ID: OSF350-069) (Case ID: HPXQA3279)
**********
When illegal user arguments are passed to the semop() system call, such that
exactly none of the requested operations work, the system call code continues
in a path that corrupts memory by depositing a PID number in areas beyond
the semaphore structure's allocated memory. When this occurs, the 16-byte
elements in kmembuckets[0] are the target of the corruption.
Due to the unpredictable nature of the consequences of the memory corruption,
there is no obvious stack trace that would point to this bug. However, here
are 3 actual traces that were caused by this bug:
> 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1903]
1 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3450]
2 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1679]
3 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
4 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213]
5 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
6 btokup() ["../../../../src/kernel/bsd/kern_malloc.c":1058]
7 free() ["../../../../src/kernel/bsd/kern_malloc.c":727]
8 fifo_buffree() ["../../../../src/kernel/vfs/fifo_vnops.c":1523]
9 fifo_close() ["../../../../src/kernel/vfs/fifo_vnops.c":525]
10 vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1220]
11 closef() ["../../../../src/kernel/bsd/kern_descrip.c":1393]
12 exit() ["../../../../src/kernel/bsd/kern_exit.c":858]
13 psig() ["../../../../src/kernel/bsd/kern_sig.c":3926]
14 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":659]
15 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1735]
1 panic("Unaligned kernel space access from kernel mode")
["../../../../src/kernel/bsd/subr_prf.c":757]
2 afault_print() ["../../../../src/kernel/arch/alpha/trap.c":1418]
3 _XentUna() ["../../../../src/kernel/arch/alpha/locore.s":1443]
4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":661]
5 semop() ["../../../../src/kernel/bsd/svipc_sem.c":1210]
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1735]
1 panic("Unaligned kernel space access from kernel mode")
["../../../../src/kernel/bsd/subr_prf.c":757]
2 afault_print() ["../../../../src/kernel/arch/alpha/trap.c":1418]
3 _XentUna() ["../../../../src/kernel/arch/alpha/locore.s":1443]
4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":661]
5 msgsnd() ["../../../../src/kernel/bsd/svipc_msg.c":1007]
6 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
7 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
FILE(s):
/usr/sys/BINARY/svipc_sem.o subset OSFBIN350
CHECKSUM: 11057 21 RCS: svipc_sem.c Revision: 4.3.51.2
===============================================================================
SUPERSEDES PATCH: OSF350-033
- DEC 8200 and 8400 systems with PCI configurations panic with the "pciaerror"
message string.
PROBLEM: (Patch ID: OSF350-071) (QAR 37795)
********
DEC 8200 and 8400 systems with PCI configurations panic with the "pciaerror"
message string.
Analysis of the error log file with DECevent shows the message:
"DMA MAP RAM INVALID ENTRY ERROR"
This problem has been observed on systems running TPC benchmarks with Tulip
Ethernet cards in a PCI slot. The problem has also been observed on other PCI
configurations, with lower frequency.
FILE(s):
/usr/sys/BINARY/dma_sg_map.o subset OSFHWBIN350
CHECKSUM: 49256 12 RCS: 1.1.46.3
/usr/sys/BINARY/pcia.o subset OSFHWBIN350
CHECKSUM: 60987 51 RCS: 1.1.44.3
===============================================================================
The bootp daemon appends a null character to file names in its responses.
PROBLEM: (Patch ID: OSF350-073) (Case ID: BRO100554)
********
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: 49780 72 RCS: bootpd.c Revision: 4.2.25.2
RCS: dovend.c Revision: 1.1.8.2
RCS: readfile.c Revision: 4.2.12.2
===============================================================================
The /sbin/scu command is currently limited to supporting 16 SCSI buses numbered
from 0 to 15.
PROBLEM: ( QAR 39259 ) ( Patch ID: OSF350-076 )
********
The /sbin/scu command is currently limited to supporting 16 SCSI buses
numbered from 0 to 15. This limitation does not match the V3.2 Base of 32
supported SCSI busses. Consequently the current /sbin/scu command cannot be
used as a SCSI utility on busses numbered from 16 to 31. This limitaiton also
affects the cluster_map_create program in the ASE and TCR products when SCSI
buses are numbered above 15.
FILE(s):
/sbin/scu subset OSFHWBASE350
CHECKSUM: 07680 632
===============================================================================
Attempting to tftpd to an aliased interface will give "ICMP Destination
unreachable" messages when multiple read requests are required to transfer data.
PROBLEM: (Patch ID: OSF350-089) (HPAQA69B2,QAR40362)
********
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: 35429 32 RCS: 4.2.11.2 (tftpd.c)
===============================================================================
Fix acctcms hash table overflow error.
PROBLEM: (Case ID: TKTQ22355) (Patch ID: OSF350-096)
********
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: 30572 32 RCS: 4.2.18.2
===============================================================================
Program translated with FreePort Express (SunOS --> Digital UNIX) binary
translator does not run correctly.
PROBLEM: (Patch ID: OSF350-097) (QAR 39134)
********
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: 48362 6 RCS: 1.1.10.2 (devz.c)
===============================================================================
A system which has a RAID set for a dump device will experience the following
problem: the system will not save the crash dump after a panic.
PROBLEM: (Case ID: MCPMA0101) (Patch ID: OSF350-100)
********
A system which has a RAID set for a dump device will experience the following
problem: the system will not save the crash dump after a panic.
FILE(s):
/usr/sys/BINARY/ruby_common.o subset OSFHWBIN350
CHECKSUM: 15102 15 RCS: ruby_common.c Revision: 1.1.25.2
===============================================================================
Programs using libexc.a suffer corrupted signal masks.
PROBLEM: (Case ID: EVT101544) (Patch ID: OSF350-102)
********
Programs linked with the libexc.a library can have their process signal masks
corrupted while handling exceptions at runtime. Theproblem 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: 09358 23
===============================================================================
Fixes file corruption on a Digital Unix NFS fileserver serving a non-Digital
Unix client. The problem was caused by client XID reuse and was originally seen
when the only nfs client was an OS/2 PC.
PROBLEM: (Patch ID: OSF350-109) (Case ID: MGO101612)
********
This correction fixes file corruption on a Digital Unix NFS fileserver serving
a non-Digital Unix client. The problem was caused by client XID reuse and was
originally seen when the only nfs client was an OS/2 PC.
If you observe server corruption and can bypass that corruption by setting the
kernel global variable 'kudp_usedrc' to zero, then you need this patch.
Do not consider turning off duplicate record checking (drc) as a solution.
Instead employ the patch so that it gets done correctly.
FILE(s):
/usr/sys/BINARY/svc_kudp.o subset OSFBIN350
Checksum:01256 85 Revision: 1.1.23.2
===============================================================================
Running tip used approximately 45% of CPU time, which was excessive.
PROBLEM: ( SOO100598 ) (Patch ID: OSF350-111)
********
Fixes the problem where running tip used approximately 45% of CPU time, which
was excessive.
Use "ps -Ocpu" to see CPU usage. Also, running vstat 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: 20044 120 RCS: tip.c Revision: 4.2.21.2
tipout.c Revision: 4.2.4.3
===============================================================================
Users could use lattelnet to invoke a subshell, a potential security issue in
some installations.
PROBLEM: (Case ID: QAR 41986 ) (Patch ID: OSF350-112)
********
Users could use lattelnet to invoke a subshell, a potential security issue in
some installations.
FILE(s):
/usr/sbin/lattelnet subset OSFLAT350
CHECKSUM: 00811 24 RCS: lattelnet.c Revision: 1.1.16.2
===============================================================================
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)
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: 28141 488
===============================================================================
Corrects a card lockup problem using the ATM IP convergence module.
PROBLEM: (Case ID: HPXQC2E60, QAR 42749 ) (Patch ID: OSF350-115)
********
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: 25354 40 RCS: if_otto.c Revision: 1.1.19.2
===============================================================================
Systems utilizing loadable PCI device driver support will fail to configure
loadable PCI device drivers when more than one PCI bus exists in a system.
PROBLEM: (QAR 42593) (Patch ID: OSF350-116)
Systems utilizing loadable pci device driver support will fail to configure
loadable pci device drivers when more than one pci bus exists in a system.
FILE(s):
/usr/sys/BINARY/stanza_resolver.o subset OSFHWBIN350
CHECKSUM: 07627 16 RCS: stanza_resolver.c Revision: 1.1.15.3
/usr/sys/BINARY/pci.o subset OSFHWBIN350
CHECKSUM: 33395 26 RCS: pci.c Revision: 1.1.95.2
/usr/sys/BINARY/ldbl_controller_support.o subset OSFHWBIN350
CHECKSUM: 32193 8 RCS: ldbl_controller_support.c Revision: 1.1.14.3
===============================================================================
A system hang or a SCSI bus hang will be experienced, when using KZMSA and
HSZ40s.
PROBLEM: (Case ID: TKTB74412 ) (Patch ID: OSF350-117)
********
A system hang or a SCSI bus hang will be experienced, when using KZMSA and
HSZ40s. There is no specific stack trace to look for, although, the
binary.errlog may log SCSI bus resets.
FILE(s):
/usr/sys/BINARY/sim_sched.o subset OSFHWBIN350
CHECKSUM: 56494 21 RCS: sim_sched.c Revision: 1.1.64.3
/usr/sys/BINARY/sim_as.o subset OSFHWBIN350
CHECKSUM: 10519 5 RCS: sim_as.c Revision: 1.1.21.3
===============================================================================
- On Digital Alpha VME 2100 Systems with EV4.5 or EV5 processors with the
embedded VIP/VIC64 VME bus adapter, the system may crash.
- System panics with a machine check, a VME adapter error occurs with an
indication that a PCI Target abort occurred, or data corruption occurs
transfering data between VME devices and system memory.
- Master Block Transfer hardware DMA performance is poor on the embedded
VIP/VIC64 VME bus of Digital Alpha VME 2100 and AXPVME systems.
PROBLEM: (QAR 43371) (Patch ID: OSF350-121)
********
On Digital Alpha VME 2100 Systems with EV4.5 or EV5 processors with the embedded
VIP/VIC64 VME bus adapter, the system may crash with console messages such as:
halted CPU 0
CPU 1 is not halted
halt code = 7
machine check while in PAL mode
PC = 18624
The PC may be different, and the halt code may be 6.
This is caused by the VME adapter's bus support code probing memory for
accessibility at a low IPL, which allows conflicting operations to occur during
the probe.
This patch fixes the problem by performing the memory probe at a higher IPL and,
during the probe, disabling some interrupts that can be caused by the probe.
PROBLEM: (QAR 43374) (Patch ID: OSF350-121)
********
System panics with a machine check, a VME adapter error occurs with an
indication that a PCI Target abort occurred, or data corruption occurs
transfering data between VME devices and system memory.
These errors can be caused by the dma_map_load kernel interface failing to
return the correct value to indicate an error.
This patch corrects the dma_map_load kernel interface so that it correctly
returns an error value.
PROBLEM: (QAR 39481) (Patch ID: OSF350-121)
********
Master Block Transfer hardware DMA performance is poor on the embedded VIP/VIC64
VME bus of Digital Alpha VME 2100 and AXPVME systems. This is caused by
incurring multiple "process dispatch latency" times between DMA segments of
large DMA transfers.
This patch improves DMA performance by reducing the number of "process dispatch
latencies" incurred to one. "Process dispatch latency" is defined as the time
between an interrupt service interface signaling a thread to execute and the
thread actually executing.
FILE(s):
/usr/sys/include/io/dec/vme/ebv10_vme.h subset OSFHWBINCOM350
CHECKSUM: 42824 135 RCS: 1.1.8.2 (ebv10_vme.h)
/usr/sys/BINARY/ebv10_vme.o subset OSFHWBIN350
CHECKSUM: 32853 71 RCS: 1.1.16.2 (ebv10_vme.c)
===============================================================================
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.
PROBLEM: (QAR 38773) (Patch ID: OSF350-130)
********
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: 22862 8 RCS: 4.2.18.2 (log.c)
===============================================================================
SUPERSEDES PATCH: OSF350-054 (54.00)
VM Fault Handling in UFS:
- Large DB application hangs in uninterruptable state.
- System panic with "ufs_getapage: allocation failed" message.
PROBLEM: (Patch ID: OSF350-054) (uvo103444)
********
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: OSF350-139)
********
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: 30645 133 RCS: 4.2.118.3 (ufs_vnops.c)
===============================================================================
A call-share executable with a text, data or bss region greater than 4 gbytes
the application will segment fault. As a work around you can build your
application non-share.
PROBLEM: (Case ID: QAR 43033) (Patch ID: OSF350-143)
********
A call-share executable with a text, data or bss region greater than 4 gbytes
the application will segment fault. As a work around you can build your
application non-share.
This test demonstrates the problem:
csh>
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>
csh> cc test.c
csh>
csh> a.out
Segmentation fault (core dumped)
csh>
FILE(s):
/sbin/loader subset OSFBASE350
CHECKSUM: 20289 112
===============================================================================
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.
PROBLEM: (Case ID: MCPM26D74, QAR 43974) (Patch ID: OSF350-144)
********
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.
For more information, consult the man pages for srconfig command.
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 i
"Idle" or "On-connecting".
FILE(s):
/usr/sys/BINARY/trn_sr.o subset OSFHWBIN350
CHECKSUM: 14566 92 RCS: trn_sr.c Revision: 1.1.19.2
===============================================================================
Big files (>10MB) take longer to copy to and from a PW-OSF server to a WfW
client than to a WNT server (NETbeui transport only).
PROBLEM: ( ZUO100334 ) (Patch ID: OSF350-149)
********
Big files (>10MB) take longer to copy to and from a PW-OSF server to a WfW
client than to a WNT server (NETbeui transport only).
FILE(s):
/usr/sys/BINARY/dlproc.o subset OSFBIN350
CHECKSUM: 06243 19 RCS: dlproc.c Revision: 1.1.13.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (Case ID: SSRT0376X ) (Patch ID: OSF350-152)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/etc/sia/OSFC2_matrix.conf subset OSFC2SEC350
CHECKSUM: 51764 3 RCS: OSFC2_matrix.conf Revision: 1.1.17.2
===============================================================================
Fixes a problem where the LAT subsystem limits the number of remote LAT nodes
on a Digital UNIX system to a maximum of 100.
PROBLEM: ( CLD HPAQ285B1, SPR STLQB0253 ) (Patch ID: OSF350-155)
********
This patch fixes a problem where the LAT subsystem limits the number of remote
LAT nodes on a Digital UNIX system to a maximum of 100. The Digital UNIX
subsystem keeps information about remote nodes which have broadcasted service
service announcement messages. On a busy local are netowrk with many LAT
devices, this maximum limit could be reached. Users may see an error message
such as "insufficent node resources" when trying to connect to the Digital UNIX
system from a terminal server or other LAT host. With this patch to latcp
installed, the LAT subsystem sets no limit on the maximum number of remote
nodes that it stores information about.
FILE(s):
/usr/sbin/latcp subset OSFLAT350
CHECKSUM: 15343 288 RCS: latctl.c Revision: 1.1.21.2
===============================================================================
Corrects system panic with the message "pnvram_write: Timed-out DMA".
PROBLEM: ( HPXQ35E83 ) (Patch ID: OSF350-156)
********
The operating system panics with the message "pnvram_write: Timed-out DMA".
The stack trace for the panicing CPU is as follows:
panic("pnvram_write: Timed-out DMA\n")
pnvram_write()
PRstrategy()
RZstrategy()
spec_strategy()
bwrite()
bawrite()
vflushbuf()
sync()
syscall()
_Xsyscall()
FILE(s):
/usr/sys/BINARY/pnvram.o subset OSFHWBIN350
CHECKSUM: 04331 13 RCS: pnvram.c Revision: 1.1.24.2
===============================================================================
Corrects a "kernel memory fault" system panic in the routine dl_set_timer().
PROBLEM: ( CLD MGO101710 ) (Patch ID: OSF350-161)
********
This patch fixes a "kernel memory fault" panic in the routine dl_set_timer().
This is a representative stack trace:
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620]
1 panic(s = 0xfffffc00005a1060 = "kernel memory fault")
["../../../../src/kernel/bsd/subr_prf.c":752]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296]
4 dl_set_timer() ["../../../../src/kernel/streamsm/dlpi/dltimer.c":152]
5 llc_i() ["../../../../src/kernel/streamsm/dlpi/dlproc.c":1830]
6 dlproc() ["../../../../src/kernel/streamsm/dlpi/dl.c":1223]
7 dllrput() ["../../../../src/kernel/streamsm/dlpi/dl.c":1300]
8 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977]
9 puthere() ["../../../../src/kernel/streams/str_util.c":1055]
10 dlb_rsrv() ["../../../../src/kernel/streamsm/dlb.c":1017]
11 sq_wrapper() ["../../../../src/kernel/streams/str_runq.c":137]
12 csq_lateral() ["../../../../src/kernel/streams/str_synch.c":977]
13 runq_run() ["../../../../src/kernel/streams/str_runq.c":108]
14 netisr_thread() ["../../../../src/kernel/net/netisr.c":821]
FILE(s):
/usr/sys/BINARY/dl.o subset OSFBIN350
CHECKSUM: 48029 84 RCS: dl.c Revision: 1.1.13.2
===============================================================================
Fixes a problem where a call to ioctl() using the TIOCM_RI mask always fails.
PROBLEM: ( HPAQ248A7 ) (Patch ID: OSF350-167)
********
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 OSFHWBIN350
CHECKSUM: 47262 28 RCS: ace.c Revision: 1.1.67.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: OSF350-169)
********
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: 56962 176 RCS: mold.c Revision: 1.1.2.8
mold_agent.c Revision: 1.1.2.2
mold_mo.c Revision: 1.1.2.2
mold_msg_text.c Revision: 1.1.2.3
sck_mold_sstb.c Revision: 1.1.6.2
===============================================================================
Fixes a problem where the find command returns a invalid status code upon
encountering a file in an "ffm" set.
PROBLEM: ( MCPM269A8 ) (Patch ID: OSF350-176)
********
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: 34753 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: OSF350-185)
********
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: 43887 32 RCS: rpc.yppasswdd.c Revision: 4.2.15.2
===============================================================================
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.
PROBLEM: ( MCPM41A3D ) (Patch ID: OSF350-186)
********
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: 58884 32 RCS: strsetup.c Revision: 4.2.29.2
===============================================================================
Adds support for file system ids ffm and nfsv3.
PROBLEM: ( MCPM4AD1A ) (Patch ID: OSF350-190)
********
This patch adds support for file system ids ffm and nfsv3. Prior 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: 09700 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
===============================================================================
Fixes the condition that results when there is no default shell in the password
file causing rexecd to fail.
PROBLEM: ( UVO103915 ) (Patch ID: OSF350-191)
********
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: 59613 24 RCS: rexecd.c Revision: 4.2.12.2
===============================================================================
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: OSF350-198)
********
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: 29095 32 RCS: rcp.c Revision: 4.2.20.2
===============================================================================
SUPERSEDES PATCHES: OSF350-200 (200.00)
This patch corrects the following:
- Fixes a problem in which the output from the df command displays incorrectly
formatted columns.
PROBLEM: ( QAR 29818 ) ( Patch ID: OSF350-200 )
********
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.
To reproduce the problem:
Run /bin/df -i and examine the output
FILE(s):
/usr/bin/df subset OSFBASE350
CHECKSUM: 21719 24 RCS: df.c Revision: 4.3.29.2
/sbin/df subset OSFBASE350
CHECKSUM: 44455 128 RCS: df.c Revision: 4.3.29.2
===============================================================================
"ping -p ff" results in a segmentation fault and core dump.
PROBLEM: ( QAR 45312 ) (Patch ID: OSF350-206)
********
"ping -p ff" results in a segmentation fault and core dump.
FILE(s):
/usr/sbin/ping subset OSFCLINET350
CHECKSUM: 62201 32 RCS: ping.c Revision: 4.2.23.2
===============================================================================
SUPERSEDES PATCH: OSF350-107 (107.00)
- After installation and configuration of a DW300 token ring option, the system
becomes unstable on boot, resulting in varied system panics.
- The token ring driver, when storing the product_id, can cause corruption which
can result in a kernel read access panic.
PROBLEM: (STLQB2393) (Patch ID: OSF350-107)
********
After installation and configuration of a DW300 token ring option, the system
becomes unstable on boot, resulting in varied system panics.
The symptom can be avoided by unplugging the token ring cable.
Fixed other problems which could result in varied panics or corruption:
o Fix IFF_PROMISC mode support.
o Fix mbuf corruption on receive path.
o Fix starting of error log thread on multiple units.
o Disable printing of some commonly occuring ring events.
o TMS380C25 and later set ring speed in the SIFACL register.
o Broadcast address wasn't accepted in ioctl.
o Reference counts were not kept on functional address additions
which result in clearing a functional address before all users
referencing it had disappeared.
o Bit reversing can occur twice when a transmit gets put back on
the if_queue when the devices xmit rings fill up.
o Open retries d o not clear when the interface is shut off.
o Added shared interrupt support (for PCI only).
o Fixed startup problem where tw o MAC_OPEN commands could be
issued simultaneously.
PROBLEM: ( UVO104380, HPAQ47704 ) (Patch ID: OSF350-208)
********
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
FILE(s):
/usr/sys/BINARY/if_tra.o subset OSFHWBIN350
CHECKSUM: 36205 60 RCS: if_tra.c Revision: 1.1.48.3
/usr/sys/data/if_tra_data.c subset OSFBINCOM350
CHECKSUM: 62090 11 RCS: 1.1.25.2 (if_tra_data.c)
/usr/sys/include/io/dec/netif/if_trareg.h subset OSFBINCOM350
CHECKSUM: 56824 19 RCS: 1.1.16.2 (if_trareg.h)
===============================================================================
SUPERSEDES PATCH: OSF350-197 (197.00)
- Fixes a problem in which the system panics when the routing code failed to
range check the destination address length.
- Fixes a problem which causes kernel memory fault in ubc_sync_iodone() due to
corruption of buffer header (struct buf).
PROBLEM: ( KAOB15145 ) (Patch ID: OSF350-197)
********
This patch fixes a problem in which the system panics when the routing
code failed to range check the destination address length. The following
is an example of a typical stack trace:
> 0 boot
1 panic(s = "kernel memory fault")
2 trap()
3 _XentMM
4 rn_match () net/radix.c:180
5 rtalloc1() net/route.c:230
6 rtalloc() net/route.c:213
7 ip_forward() netinet/ip_input.c:1572
8 gw_forwardscreen() data/gw_screen_data.c:56
9 ip_forwardscreen() netinet/ip_screen.c:62
10 ipintr() netinet/ip_input.c:642
11 netisr_thread() net/netisr.c:806
PROBLEM: ( MGO101960 ) (Patch ID: OSF350-211)
********
This patch resolves a problem which causes kernel memory fault
in ubc_sync_iodone() due to corruption of buffer header (struct buf).
FILE(s):
/usr/sys/BINARY/route.o subset OSFBIN350
CHECKSUM: 55484 97 RCS: rtsock.c Revision: 4.2.21.2
===============================================================================
SUPERSEDES PATCHES: OSF350-213 (213.00)
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.
PROBLEM: (QAR 39624) (Patch ID: OSF350-213-1)
********
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: 46068 264 RCSfile: comstart.c RCS: 1.1.8.3
===============================================================================
Fixes a problem that occurs when the -b option of the volrecover command is
used. The problem is that a background job spawned to perform the recovery
operation fails when a SIGHUP signal is received.
PROBLEM: ( QAR38631 ) (Patch ID: OSF350-216)
This patch fixes a problem that occurs when the -b option of the volrecover
command is used. The problem is that a background job spawned to perform the
recovery operation fails when a SIGHUP signal is received. This patch ensures
that the background job ignores the SIGHUP signal.
FILE(s):
/sbin/volrecover subset OSFLSMBASE350
CHECKSUM: 11642 160
===============================================================================
Automount can take up more memory than is necessary due to a memory leak.
PROBLEM: ( HPAQ46F6F ) (Patch ID: OSF350-218)
********
Automount can take up more memory than is necessary due to a memory leak.
In this case a 'ps -l' command showed a vsize of 64MB, and the daemon.log
file showed an entry for automount
"Memory allocation failed: not enough space".
In some cases this leak can cause applications to hang.
FILE(s):
/usr/sbin/automount subset OSFNFS350
CHECKSUM: 38204 104
===============================================================================
Fixes a halt/restart problem with the mfa driver ESP self-test.
PROBLEM: ( ZPOB30186 / QAR 46022 ) (Patch ID: OSF350-221)
********
This patch fixes a halt/restart problem with the mfa driver ESP self-test.
If the DEMFA interface halts, self-tests are performed. The mfareset routine
contained a bug which prevented the interface from restarting after the halt.
The DEMFA interface may also halt due to it's inability to allocate (malloc)
memory for it's buffers. The correction for the malloc problem is contained
in the MANDATORY PATCH.
Typical error messages in the /var/adm/messages file will include:
mfa: port halted (eintr): xber = 0x8a, xpst = 0xc1805,
xpd1 = 0x183f8000, xpd2 = 0x0, xpud = 0x8c5d001c
The 'c' in the XPST indicates that the ESP special test failed.
If your system panics, your stack will look as follows:
_XentMM()
mfareset()
mfainit()
mfaioctl()
in_ifinitia()
in_control()
udp_usrreq()
ifioctl()
FILE(s):
/usr/sys/BINARY/if_mfa.o subset OSFHWBIN350
CHECKSUM: 54635 46 RCS: if_mfa.c Revision: 1.1.49.2
===============================================================================
SUPERSEDES PATCH: OSF350-175 (175.00)
- Fixes problems with the rpc.pcnfsd program that can cause rpc.pcnfsd to
crash. When rpc.pcnfsd crashes, the pc nfs service will disappear.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: ( HPAQA2303 HPAQ347D8 37411 ) (Patch ID: OSF350-175)
********
- This patch fixes problems with the rpc.pcnfsd program that can cause
rpc.pcnfsd to crash. When rpc.pcnfsd crashes, the pc nfs service will
disappear.
If either of the following circumstances exist,
the rpc.pcnfsd program could crash:
1) When a system is running C2 security and an account is locked
because of too many illegal login attempts.
2) When making a second attempt to mount an NFS file system
that failed to mount during the first attempt.
- This patch also fixes a problem where pcnfsd does not generate audit events
for successful pcnfsd authorizations (auth_event "succeed" events).
PROBLEM: ( SSRT0396U, QAR 45778 ) (Patch ID: OSF350-223)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/sbin/rpc.pcnfsd subset OSFNFS350
CHECKSUM: 47183 56
===============================================================================
savings time.
PROBLEM: ( GOZ100495 ) (Patch ID: OSF350-224)
********
In Fall of 1996, the member countries of the EC (European Community) will all
change timezone rules to switch to normal time from daylight savings time on
the last Sunday in October. Most countries previously did this in September.
Without this patch, all Digital UNIX releases prior to v4.0 will use the old
rules. If you are running a pre-v4.0 release of Digital UNIX and use (or
operate in) any of the above timezones, you will need this patch to effect the
daylight savings time change at the correct date/time.
FILE(s):
/etc/zoneinfo/London subset OSFBASE350
CHECKSUM: 30843 2
/etc/zoneinfo/Belfast subset OSFBASE350
CHECKSUM: 12469 2
/etc/zoneinfo/Dublin subset OSFBASE350
CHECKSUM: 38262 2
/etc/zoneinfo/GB-Eire subset OSFBASE350
CHECKSUM: 30843 2
/etc/zoneinfo/Poland subset OSFBASE350
CHECKSUM: 11037 1
/etc/zoneinfo/WET subset OSFBASE350
CHECKSUM: 46878 1
/etc/zoneinfo/MET subset OSFBASE350
CHECKSUM: 53651 1
/etc/zoneinfo/EET subset OSFBASE350
CHECKSUM: 50518 1
/etc/zoneinfo/W-SU subset OSFBASE350
CHECKSUM: 27357 1
/etc/zoneinfo/CET subset OSFBASE350
CHECKSUM: 53651 1
/etc/zoneinfo/sources/europe subset OSFBASE350
CHECKSUM: 60208 36
===============================================================================
The cd_defs(CD_GETDEFS) library function returns the wrong default uid and gid
for an ISO9660 CD-ROM.
PROBLEM: ( QAR41743 ) (Patch ID: OSF350-230)
The cd_defs(CD_GETDEFS) library function returns the wrong default uid and gid
for an ISO9660 CD-ROM.
FILE(s):
/usr/ccs/lib/libcdrom.a subset OSFPGMR350
CHECKSUM: 60877 18
/usr/shlib/libcdrom.so subset OSFBASE350
CHECKSUM: 14730 40
===============================================================================
Fixes a problem where the System V getdirentries() system call did not correctly
calculate the number of entries in a directory inode when accessing the /dev/fd
filesystem.
PROBLEM: ( QAR39830 ) (Patch ID: OSF350-231)
This patch fixes a problem where the System V getdirentries() system call did
not correctly calculate the number of entries in a directory inode when
accessing the /dev/fd file system. The problem resulted in the readdir()
function returning erroneous directory entries when used on the /dev/fd file
system and also caused error messages to be produced by the ksh builtin dir
command when used on /dev/fd.
Error messages such as the following are typical:
stat: /dev/fd/ptyq9: No such file or directory
stat: /dev/fd/ttyq9: No such file or directory
stat: /dev/fd/ptyqa: No such file or directory
stat: /dev/fd/ttyqa: No such file or directory
The problem can be reproduced by using the System V ksh builtin dir command
on /dev/fd.
FILE(s):
/usr/sys/BINARY/fdfs_vnops.o subset OSFBIN350
CHECKSUM: 25116 10
===============================================================================
Fixes a problem in which the find command will not handle more than 100
arguments.
PROBLEM: ( USG-02753 ) (Patch ID: OSF350-237)
********
The patch corrects a problem in which the find command will not handle
more than 100 arguments. Given more tha 100 arguments, the find command
used to terminate with the following error message: "find: Too many options".
FILE(s):
/usr/bin/find subset OSFBASE350
CHECKSUM: 09883 40 RCS: find.c Revision: 4.3.35.2
===============================================================================
Mail sent using uucp, or output to Mail from the uux command causes the mail
message to be sent from the daemon to root with the following error message:
"remote access to path/file denied". The error message is sent to root in a
mail message.
PROBLEM: ( ) (Patch ID: OSF350-238)
********
Mail sent using uucp, or output to Mail from the uux command causes the mail
message to be sent from the daemon to root with the following error message:
"remote access to path/file denied". The error message is sent to root in a
mail message.
To determine whether this problem exists on your system run the following test:
cal | uux -r - SITE\!/bin/Mail -s test2 USER
where SITE is the name of a remote site and USER is a user on
that site.
FILE(s):
/usr/bin/uux subset OSFUUCP350
CHECKSUM: 55852 344 RCS: uux.c Revision: 4.3.12.2
===============================================================================
SUPERSEDES PATCHES: OSF350-162 (162.00), OSF350-171 (171.00)
- Fixes a problem where an attribute had been set to "read only" and the
built-in command typeset (eg. typeset +r ) could not set it back (unset)
to "read/write" status.
- Fixes a problem in which a system running ksh as the login shell would wipe
out the previous contents of the history file (for example, .sh_history) and
put the new information in the file.
- In some cases, the tty modes have been reset. This problem occurs after
exiting a ksh session.
PROBLEM: ( HPAQ22AF7 ) (Patch ID: OSF350-162)
********
This patch fixes a problem where an attribute had been set to "read only"
and the built-in command typeset (eg. typeset +r ) could not set
it back (unset) to "read/write" status.
If the built-in command 'typeset +r ' is entered after an attribute has
been set to 'read-only' status (eg. typeset -r attr=val), the following message
is displayed:
ksh: : is read only.
Enter 'typeset -r ' and then enter 'typeset +r '. As a result,
an error message will be issued.
PROBLEM: ( USG-01932 ) (Patch ID: OSF350-171)
********
This patch fixes a problem in which a system running ksh as the login shell
would wipe out the previous contents of the history file (for example,
.sh_history) and put the new information in the file. This occurred after a
user logged into an ULTRIX system from an OSF/1 system using the telnet or
rlogin commands.
On an associated Ultrix machine, an official patch for cld HPAQ6E7B needs to
be installed when it uses the NFS mounted filesystem from the UNIX machine.
Do the following to reproduce this problem:
1. Setup a new account on an OSF/1 V3.2C
with /bin/ksh as the login SHELL and with the home
directory NFS mounted from an ULTRIX system.
2. Rlogin into the OSF/1 system from an ULTRIX system
and issue a few commands. Make sure "history" shows the
commands you just issued. Cat ".sh_history" just to sanity
check what's in there; logout.
3. Rlogin into the ULTRIX system and issue a few commands. Then
cat ".sh_history" file and see whether the previous commands
get written from the OSF/1 system or the ULTRIX system.
You can see new commands from the ULTRIX system get written into the
.sh_history file, but the commands from the OSF/1 system get wiped out.
4. Rlogin into the OSF/1 system again from the ULTRIX
system. Cat ".sh_history" to ensure that the ULTRIX commands still
exist, then enter a few commands.
Finally, cat ".sh_history" file and notice that the previous
ULTRIX commands get wiped out.
PROBLEM: ( ) (Patch ID: OSF350-239)
********
This problem occurs after exiting a ksh session. In some cases, the tty
modes have been reset. A tty sane is needed to restore the
modes.
When this problem occurs, keyboard input is not echoed after ksh is
exited.
execute the following:
/usr/bin/ksh
set -o emacs
touch /tmp/foo
trap 'rm -f /tmp/foo' EXIT
TMOUT=1
Now wait 60 seconds. When the ksh exits, the keyboard should echo characters.
If it does not, then this bug has occured.
FILE(s):
/usr/bin/ksh subset OSFBASE350
CHECKSUM: 38536 272
===============================================================================
Add the time out options -t nnn & -T to the "showmount" command.
PROBLEM: (HPXQ36487/QAR 46954) (Patch ID: OSF350-240)
********
If the "showmount -e host" command does not receive the requested export
list from the specified host within 25 seconds, it will issue the
following error message:
Can't do Exports rpc: RPC: Timed out
The most likely cause for receiving this error is if the specified host
system is running a 3rd party product that provides its own file system
interface _AND_ if accessing that file system is slow (perhaps on the
first reference to the file system) _AND_ if a sufficient number of such
file systems are exported so that 'mountd' takes a long time to read and
verify the list of exported file systems.
Generally speaking, 'mountd' is able to read and verify its export list
in less than a second or a few seconds worst case for a very large list.
However, if conditions do exist that would cause 'showmount' to issue
the above error, then this version of 'showmount' provides options that
will allow the time out value to be changed.
-t nnn specifies the time out value in seconds.
-T specifies an infinite time out.
FILE(s):
/usr/bin/showmount subset OSFNFS350
CHECKSUM: 28065 24 RCS: showmount.c Revision: 4.2.10.2
===============================================================================
- Fixes a problem that occurs on a multiprocessor system in which the pfm
driver does not provide any profiling data on CPUs other than #0.
- Fixes a problem that occurs on systems with recent CPU hardware (EV5) in which
using the kprofile command will cause the system to hang.
PROBLEM: (QAR 42434) ( Patch ID: OSF350-241 )
********
Fixes a problem that occurs on a multiprocessor system in which the pfm driver
does not provide any profiling data on CPUs other than #0.
Specifically, when the "runon" command is used to profile on a cpu other than
#0, the uprofile command does not get any profile data from the pfm driver when
its -one switch is specified. For example:
% runon 1 kprofile -one ls -l
PROBLEM: (QAR 39284 QAR 38600) ( Patch ID: OSF350-241 )
********
Fixes a problem that occurs on systems with recent CPU hardware (EV5)
in which using the kprofile command will cause the system to hang.
In rare cases the system will not hang, but the profiling data
produced will have all zero counts.
FILE(s):
/usr/sys/BINARY/pfm.o subset OSFBIN350
CHECKSUM: 60414 16 RCS: pfm.c Revision: 1.1.29.2
/usr/ccs/lib/cmplrs/cc/uprofile subset OSFCMPLRSEXT350
CHECKSUM: 25072 120 RCS: uprofile.c Revision: 1.1.16.2
===============================================================================
Fixes a problem in which the size field of a process displayed by
the acctcom command is displayed incorrectly.
PROBLEM: (TKTQ72352) (Patch ID: OSF350-247)
********
This patch fixes a problem in which the size field of a process
displayed by the acctcom command is displayed incorrectly.
Typically, processes that use a lot of memory will display very invalid
size values. These sizes will either be absurdly large or negative.
Compile and run the following program. Acctcom will display a size that
is about 8 times larger than the actual memory usage.
#include
#include
#include
#include
#include
#define ALLOC_SIZE 1024 * 1024 /* 1M byte */
main()
{
int i;
struct rusage ru;
i = fork();
if (i == 0) {
child();
}
else {
wait3(NULL,0,&ru);
printf("size information %ld %ld %ld\n",ru.ru_ixrss,ru.ru_idrss,ru.ru_isrss);
}
}
child()
{
int counter;
int i;
char *address;
for( counter = 1 ; counter < 100 ; counter++ ) {
address = ( char * )malloc( sizeof( char ) * ALLOC_SIZE );
if( address == NULL ) {
printf( "Can't allocate memory.\n" );
sleep( 60 );
exit( 0 );
}
for( i = 0 ; i < ALLOC_SIZE ; i++ ) {
*address = ( char )( counter % 255 );
address ++;
}
printf( "Allocate %5dM byte\n" , counter );
}
exit( 1 );
}
FILE(s):
/usr/bin/acctcom subset OSFACCT350
CHECKSUM: 47975 40 RCSfile: acctcom.c RCS: 4.3.20.2
===============================================================================
SUPERSEDES PATCHES: OSF350-249 (249.00)
This patch corrects the following:
Multiple mounts of the same file system under the Optical file system
may fail with ERRNO = 169.
PROBLEM: (UV0104402, QAR 46852) (Patch ID: OSF350-249-1)
********
Multiple mounts of the same file system under the Optical file system
may fail with ERRNO = 169.
This occurs when a user invokes the mount system call from within
a program twice, such as Mount-unmount-mount operations on the
Optical Filesystem. The LMF license units may not be released
causing the future mounts to fail. The mount system call will fail
the second time with ERRNO = 169.
FILE(s):
/usr/sys/BINARY/kern_lmf.o subset OSFBIN350
CHECKSUM: 60285 12 RCS: kern_lmf.c Revision: 1.1.30.2
===============================================================================
SUPERSEDES PATCHES: OSF350-072 (72.00), OSF350-095 (95.00),
OSF350-215 (215.00)
- If a file from a remote nfs mounted directory is mmapped, removed on the
server, and msynced from the client, the client machine can hang.
- Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
- 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.
PROBLEM: (Patch ID: OSF350-072) (Case ID: MCPMA9CF9, QAR 33924)
********
If a file from a remote nfs mounted directory is mmapped, removed on the
server, and msynced from the client, the client machine can hang.
A typical stack from a forced crash dump is:
> 0 ubc_page_release
1 ubc_sync_iodone
2 nfs3_rwblk
3 nfs3_putpage
4 ubc_msync
PROBLEM: (Case ID: BRO100600) (Patch ID: OSF350-095)
********
Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
PROBLEM: ( QAR 33924 ) (Patch ID: OSF350-215)
********
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: OSF350-250)
********
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 OSFBIN350
CHECKSUM: 47592 42 RCS: nfs_vnodeops.c Revision: 1.1.84.6
/usr/sys/BINARY/nfs3_vnodeops.o subset OSFBIN350
CHECKSUM: 09432 50 RCS: nfs3_vnodeops.c Revision: 1.1.46.4
===============================================================================
SUPERSEDES PATCHES: OSF350-204 (204.00), OSF350-229 (229.00)
- SVR4 STREAMS documentation is being violated because a valid device id is
not being passed by the push function when a module is pushed on the stream.
Instead, a zero value is being set.
- A customer-written device driver attempts to return a customer-defined error
value that is out of the defined range (0-128) the value EINVAL is returned
instead.
- Set the device number to zero or the actual value to prevent the hang caused
by patch OSF350-229.
PROBLEM: ( HPAQB5D39, MXOQ10017 ) (Patch ID: OSF350-204)
********
This problem occurs when unlinking STREAMS Multplexors. Note that there are no
STREAMS multiplexors included in the base system but they are used by Layered
products (e.g., DECnet, PATHworks, SNA Peer Server). Typically unlinking
occurs when shutting down a layered product but PATHworks is an exception to
this.
The panic has the general stack trace below:
trap()
_XentMM()
sq_wrapper()
csq_lateral()
runq_run()
netisr_thread()
PROBLEM: ( QAR 46691 ) (Patch ID: OSF350-229)
********
The SVR4 STREAMS documentation is being violated because a valid device id is
not being passed by the push function when a module is pushed on the stream.
Instead, a zero value is being set.
PROBLEM: ( QAR 46828 ) (Patch ID: OSF350-252)
********
When a customer-written device driver attempts to return a customer-
defined error value that is out of the defined range (0-128) the
value EINVAL is returned instead.
PROBLEM: ( QAR 47488 ) (Patch ID: OSF350-252)
********
A system that has Patch OSF350-229 installed may hang. Patch OSF350-229
corrects a situation in which the SVR4 STREAMS documentation could be violated.
It allows a device number to be pushed on the stream. The current patch will
set the device number to zero or the actual value to prevent the hang caused
by patch OSF350-229.
IMPORTANT: As described above, patch OSF350-252 contains the CORRECTION to
patch OSF350-229 which had been declared as DEFECTIVE, and
temporarily withdrawn, via email notification dated 20-jul-1996.
FILE(s):
/usr/sys/BINARY/str_osr.o subset OSFBIN350
CHECKSUM: 14554 43 RCS: str_osr.c Revision: 4.2.48.4
===============================================================================
This patch fixes two problems that occur when an application is started
from a subshell, for example, sh -c :
o An application will hang if it receives an interrupt signal, for
example, if the user enters Ctrl/C.
o While an application is running, if Ctrl/C is entered, the parent
process exits, but the child process remains.
PROBLEM: ( SOO100674 ) (Patch ID: OSF350-256)
********
This patch fixes a problem that occurs when an application is started from
a subshell, for example, sh -c . The application will hang if it
receives an interrupt signal, for example, the user enters Ctrl/C.
PROBLEM: ( STLB81811 ) (Patch ID: OSF350-256)
********
This patch fixes a problem that occurs when running an application inside
a shell. When the user enters Ctrl/C, the parent process exits, but the
child process remains.
FILE(s):
/usr/bin/sh subset OSFBASE350
CHECKSUM: 61157 128
/usr/bin/Rsh subset OSFBASE350
CHECKSUM: 61157 128
/sbin/sh subset OSFBASE350
CHECKSUM: 54814 224
/sbin/Rsh subset OSFBASE350
CHECKSUM: 54814 224
===============================================================================
The first "From" line in an incoming non-local mail message indicates the mail
is from "daemon" rather than the actual sender.
PROBLEM: ( CLD HPAQ1279F, HPXQB539D ) (Patch ID: OSF350-263)
********
The first "From" line in an incoming non-local mail message indicates the mail
is from "daemon" rather than the actual sender. This confused programs such as
"from" and certain third-party mail handlers.
FILE(s):
/usr/bin/binmail subset OSFBASE350
CHECKSUM: 39585 40 RCS: binmail.c Revision: 4.3.38.2
/usr/bin/mail subset OSFBASE350
CHECKSUM: 39585 40 RCS: binmail.c Revision: 4.3.38.2
===============================================================================
Fixes a problem with the mkpasswd command.
PROBLEM: ( HPAQ31FCB ) (Patch ID: OSF350-268)
********
This patch fixes a problem with the mkpasswd command. Hashed password
database files (for example, /etc/passwd.pag and /etc/passwd.dir) are
deleted before new database files are created.
To recreate the problem, complete the following steps:
1. Log in as root.
2. Select a very large password file and enter the following command:
ls -l /etc/passwd*
3. Verify the byte count of the /etc/passwd.pag and /etc/passwd.dir files.
4. Enter the following command:
mkpasswd -v /etc/password
5. While the mkpasswd command is running, open another window and
verify the byte count of the /etc/passwd.pag and /etc/passwd.dir
files. Note that these files will be removed before new ones
are created.
FILE(s):
/usr/sbin/mkpasswd subset OSFBASE350
CHECKSUM: 10108 24 RCS: mkpasswd.c Revision: 4.2.15.2
===============================================================================
A process may hang while attempting to obtain a file lock using flock() when
run on an SMP system.
PROBLEM: (CLD TKTR72070/QAR 47885) (Patch ID: OSF350-269)
********
A process may hang while attempting to obtain a file lock using flock() when
run on an SMP system. A dbx stack trace on a running system would look
similar to the following:
0 thread_block() ["../../../../src/kernel/kern/sched_prim.c"]
1 mpsleep() ["../../../../src/kernel/bsd/kern_synch.c"]
2 vn_flock() ["../../../../src/kernel/vfs/vfs_vnops.c"]
3 flock() ["../../../../src/kernel/bsd/kern_descrip.c"]
4 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
5 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]
The hung process can be interrupted with Control/C or any other kill SIGNAL.
This situation can occur if multiple processes are locking and unlocking the
same file using the flock() system call on an SMP system. This problem will
not occur on a single CPU system.
FILE(s):
/usr/sys/BINARY/vfs_vnops.o subset OSFBIN350
CHECKSUM: 55796 18 RCS: vfs_vnops.c Revision: 4.3.79.2
===============================================================================
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.
PROBLEM: ( MCPM750D6 HPXQ36ADF ) (Patch ID: OSF350-271)
********
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"
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c"
3 xcpu_puts() ["../../../ ../src/kernel/bsd/subr_prf.c"
4 printf() ["../../../../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_trap.c"
17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"
FILE(s):
/usr/sys/BINARY/vfs_cache.o subset OSFBIN350
CHECKSUM: 48914 56 RCS: vfs_cache.c Revision: 4.2.47.2
===============================================================================
Fixes a problem that occurs when using the rmt program to access devices or
files.
PROBLEM: ( TPOQ70260 ) (Patch ID: OSF350-273 )
********
This patch fixes a problem that occurs when using the rmt
program to access devices or files. The rmt program does not accept
reads/writes of less than 1024 bytes. The system displays the
following error message:
Cannot set socket receive buffer size
FILE(s):
/usr/sbin/rmt subset OSFCLINET350
CHECKSUM: 61729 24 RCS: rmt.c Revision: 4.2.11.2
===============================================================================
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: OSF350-274)
********
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 OSFBASE350
CHECKSUM: 57231 112 RCS: edquota.c Revision: 4.2.7.4
/usr/sbin/quota subset OSFBASE350
CHECKSUM: 13077 112 RCS: quota.c Revision: 4.2.15.4
rquotaxdr.c Revision: 4.2.4.2
/usr/sbin/vedquota subset OSFADVFS350
CHECKSUM: 29504 576 RCS: vedquota.c Revision: 1.1.15.4
/usr/sbin/vquota subset OSFADVFS350
CHECKSUM: 46579 504 RCS: vquota.c Revision: 1.1.8.4
===============================================================================
SUPERSEDES PATCHES: OSF350-275 (275.00)
This patch corrects the following:
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0416U, QAR 48450) (Patch ID: OSF350-275-1)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/bin/rlogin subset OSFCLINET350
CHECKSUM: 16062 32 RCS: rlogin.c Revision: 4.2.23.2
===============================================================================
When a member of the group "operator" logged into the console and dump was
invoked with the -n option, an extraneous file (/dev/:0) was created.
PROBLEM: ( HPXQ7269D ) (Patch ID: OSF350-278)
********
When a member of the group "operator" logged into the console and
dump was invoked with the -n option, an extraneous file (/dev/:0) was created.
FILE(s):
/usr/sbin/dump subset OSFHWBASE350
CHECKSUM: 34058 80 RCS: dumpmain.c Revision: 4.2.29.2
/sbin/dump subset OSFHWBASE350
CHECKSUM: 22837 328 RCS: dumpmain.c Revision: 4.2.29.2
/usr/sbin/rdump subset OSFCLINET350
CHECKSUM: 03055 80
===============================================================================
- The system can hang ffter the appearance of binary.errlog entries:
sim_err_sm Target went to command phase
sim94_intr Illegal command
- Fixes a bug in the SIM94 interrupt handler where the target mode flag for
a controller was being set before a previous non-target mode request was
completed.
PROBLEM: ( mgo102246 ) (Patch ID: OSF350-282)
********
After the appearance of binary.errlog entries:
sim_err_sm Target went to command phase
sim94_intr Illegal command
The system can hang with the following typical stack trace:
0 ss_process_timeouts() [src/kernel/io/cam/sim_sched.c:2572]
1 softclock_scan() [src/kernel/bsd/kern_clock.c:1015]
2 hardclock("") [src/kernel/bsd/kern_clock.c:839]
3 _XentInt() [src/kernel/arch/alpha/locore.s:917]
4 idle_thread() [src/kernel/kern/sched_prim.c:3009]
PROBLEM: ( QAR 29649 ) (Patch ID: OSF350-282)
********
Fix system panic: "xpt_callback: callback on freed CCB".
The panic described in this QAR was caused by a bug in the SIM94
interrupt handler where the target mode flag for a controller
was being set before a previous non-target mode request was
completed.
FILE(s):
/usr/sys/BINARY/sim_94.o subset OSFHWBIN350
CHECKSUM: 08977 168 RCS: sim_94.c Revision: 1.1.72.2
/usr/sys/include/io/cam/sim.h subset OSFBINCOM350
CHECKSUM: 22619 32 RCS: sim.h Revision: 1.1.44.2
===============================================================================
When typing "more a_particular_file" there is garbage displayed on the
screen, while displaying files having lines ending with ^M character.
PROBLEM: ( STLQ73538/QAR 48009 ) (Patch ID: OSF350-285)
********
When typing 'more a_particular_file' there is garbage displayed on the
screen, while displaying files having lines ending with ^M character.
FILE(s):
/usr/bin/more subset OSFBASE350
CHECKSUM: 56919 88
/usr/bin/page subset OSFBASE350
CHECKSUM: 56919
===============================================================================
Fixes a problem in which a non-timeshared (i.e., fixed priority) thread
running on a multiprocessor system is inappropriately given a priority boost
when returning from a funnelled subsystem.
PROBLEM: ( QAR44344 ) (Patch ID: OSF350-286)
********
This patch fixes a problem in which a non-timeshared (i.e., fixed priority)
thread running on a multiprocessor system is inappropriately given a priority
boost when returning from a funnelled subsystem. Unfortunately, the symptom
of this problem is a system hang.
FILE(s):
/usr/sys/BINARY/parallel.o subset OSFBIN350
CHECKSUM: 04287 10 RCS: parallel.c Revision: 4.2.36.2
===============================================================================
Some valid programs compiled with ieee mode may receive a floating-point
exception even though they should run to completion.
PROBLEM: (QAR 36520, QAR 48372) (Patch ID: OSF350-287)
********
Some valid programs compiled with ieee mode may receive a floating-point
exception even though they should run to completion. The problem occurs
because the floating-point exception handler is too strict when attempting
to enforce trap shadow rules (SRM 4.7.6.1). The following C program fails
when executed on a system with a DECchip 21064.
Compile the following program with the command:
cc -migrate -g -ieee_with_inexact t.c -o t
f( int dum, ... ) {
}
main() {
int ii = 50;
f( 42,
(float)ii / 100,
(float)ii / 100,
(float)ii / 100 );
}
Results on a system with a 21046 chip before applying the patch:
quarry:ieee/48372 [4%] cc -migrate -g -ieee_with_inexact t.c -o t
quarry:ieee/48372 [5%] ./t
Floating exception(coredump)
Results after applying the patch:
sauron:ieee/48372 [2%] ./t
sauron:ieee/48372 [3%]
FILE(s):
/usr/sys/BINARY/fp_trigger.o subset OSFHWBIN350
CHECKSUM: 08649 6 RCS: fp_trigger.c Revision: 1.1.18.2
===============================================================================
The code generator used an incorrect codegen sequence when doing stack
allocation within procedure prologs where the size of the stack was very large
(for example, when a structure is passed as an entity rather than as a pointer).
PROBLEM: ( TKTQ51382 QAR 46989 ) (Patch ID: OSF350-289)
********
The code generator used an incorrect codegen sequence when doing stack
allocation within procedure prologs where the size of the stack was very large
(for example, when a structure is passed as an entity rather than as a pointer).
This led to an improper instruction sequence where a register value was
dereferenced as an address pointer, when in fact the register was a temp and
had just been corrupted by a previous function call which generated the error
message
"Segmentation fault (core dumped)".
FILE(s):
/usr/ccs/lib/cmplrs/cc/ugen subset OSFCMPLRS350
CHECKSUM: 60291 864
===============================================================================
SUPERSEDES PATCHES: OSF350-233 (233.00)
This patch corrects the following:
- A problem that occurs on multi-processor machines in which the at command
causes extra batch jobs to be executed. Sometimes temporary files are created
and not removed, causing the queue limit to be exceeded.
- Fixes a problem in which cron jobs will not run if there is an unfinished job
in another queue. This problem occurs even if the queue for the job is empty.
PROBLEM: (HPAQ40CCC) (Patch ID: OSF350-233)
********
This patch fixes a problem in which cron jobs will not run if there is an
unfinished job in another queue. This problem occurs even if the queue for
the job is empty.
Typically, a long job is the only job scheduled from cron. After that job
terminates, another cron job starts executing. This results in several
"MAXRUN procs reached" messages getting displayed to the error
log. The /var/adm/cron/FIFO file, which should only exist while jobs remain
queued, remains around much longer than expected.
This problem can be reproduced by running the following test. To do this,
you need three windows running the following commands:
truss -p You might want to script
tail -f /var/cron/log the truss and batch_two.ksh
batch_two.ksh processes.
The batch_two.ksh file is:
#!/bin/ksh
echo "sleep 9999" | batch
integer COUNT=1
while [ COUNT -lt 60 ] ; do
echo "sleep 15" | batch
(( COUNT = COUNT + 1 ))
done
(
sleep 222
echo "sleep 700" | at -qr now +1 minute
echo "sleep 750" | at -qr now +1 minute
echo "sleep 800" | at -qs now +1 minute
echo "sleep 14" | batch
) &
integer STOP=0 PS
while [ $STOP -eq 0 ] ; do
atq | tee /tmp/atq.out
ps -ef|grep sleep | tee /tmp/ps.out
ls -l /etc/cron.d/FIFO
date
PS=`cat /tmp/ps.out | wc -l`
AT=`cat /tmp/atq.out`
[ $PS -le 1 -a "$AT" = "no files in queue." ] && STOP=1 || sleep 10
done
echo "$0 finished."
rm -f /tmp/atq.out /tmp/ps.out
integer STOP=0 PS
while [ $STOP -eq 0 ] ; do
atq | tee /tmp/atq.out
ps -ef|grep sleep | tee /tmp/ps.out
ls -l /etc/cron.d/FIFO
date
PS=`cat /tmp/ps.out | wc -l`
AT=`cat /tmp/atq.out`
[ $PS -le 1 -a "$AT" = "no files in queue." ] && STOP=1 || sleep 10
done
echo "$0 finished."
rm -f /tmp/atq.out /tmp/ps.out
The previous test shows that a long running job will prevent cron from
scheduling jobs from any queue until one of the following events occur:
1) The long running job exits, or
2) Cron exhausts the FIFO list of already completed jobs
(one minute per job)
Either of these conditions may take a very long time. For a long running job,
such as a part14 report, it may be hours. It could take cron a very long time
to exhaust the FIFO list at one minute per job (200 completed jobs = 3.3 hours).
The intertesting part of the test occurs when the background sleep 222
completes and places the four new jobs in queues r, s, and b. These jobs will
wait for a long time when they do not need to wait at all.
PROBLEM: (QAR 47149, UVO104578CBR) (Patch ID: OSF350-291)
********
This patch fixes a problem that occurs on multi-processor machines in which the
at command causes extra batch jobs to be executed.
Sometimes temporary files are created and not removed, causing the queue limit
to be exceeded.
FILE(s):
/usr/sbin/cron subset OSFBASE350
CHECKSUM: 61915 48 RCSfile: cron.c RCS: 4.2.34.3
===============================================================================
Processes such as wall or ntalkd, when connected to LAT terminal devices,
are hanging when attempting to close, possibly because the LAT sessions
have been disconnected abnormally.
PROBLEM: ( DMO100204, HPXQ974C9 ) (Patch ID: OSF350-293)
********
Processes such as wall or ntalkd, when connected to LAT terminal devices,
are hanging when attempting to close, possibly because the LAT sessions
have been disconnected abnormally. A tstack trace in dbx of a hung process
should look similar to this:
0 thread_block()
1 mpsleep()
2 streams_mpsleep()
3 latsclose()
4 close_wrapper()
5 csq_protect()
6 osr_pop_subr()
7 osr_close_subr()
8 pse_close()
9 speclose()
10 clearalias()
11 exit()
12 rexit()
13 syscall()
14 _Xsyscall()
FILE(s):
/usr/sys/BINARY/latclose.o subset OSFBIN350
CHECKSUM: 63488 7 RCS: latclose.c Revision: 1.1.17.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (Patch ID: OSF350X-002) (SSRT0358X)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/bin/X11/dxconsole subset OSFX11350
CHECKSUM: 51497 32
/usr/bin/X11/xconsole subset OSFX11350
CHECKSUM: 51497 32
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (Patch ID: OSF350X-003) (Case ID: SSRT0356U)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/tcb/bin/dxchpwd subset OSFXC2SEC350
CHECKSUM: 41050 48 RCS: 1.1.6.2 (dxchpwd_ui.c)
===============================================================================
X font Server Correction:
The X font server will sometimes crash when serving fonts to a system with
big-endian byte ordering such as an NCD X terminal.
PROBLEM: (Patch ID: OSF350X-006) (HPXQA2963,ISO100156,HPXQA3243)
********
The X font server will sometimes crash when serving fonts to a system
with big-endian byte ordering such as an NCD X terminal.
The stack traces in the resulting core files will vary, but often Xalloc()
FSalloc(), and malloc() will be at the top of the stack.
FILE(s):
/usr/bin/X11/fs subset OSFX11350
CHECKSUM: 14088 184
===============================================================================
X Server Display Postscript Correction:
There is a problem in the X server Display PostScript code that can cause
incorrect colors to be displayed when using a gray ramp with only two cells
with a visual of depth greater than 1.
PROBLEM: (Case ID: MGO101537) (Patch ID: OSF350X-011)
********
There is a problem in the X server Display PostScript code that can cause
incorrect colors to be displayed when using a gray ramp with only two cells
with a visual of depth greater than 1.
FILE(s):
/usr/shlib/X11/lib_adobe_dps.so subset OSFSER350
CHECKSUM: 23989 3376 RCS: 1.1.6.2 (xdirect.c)
RCS: 1.1.6.2 (xwinext.c)
===============================================================================
SUPERSEDES PATCHES: OSF350X-005 (315.00), OSF350X-008 (318.00)
Corrects the following xdm and Xlib problems:
- xdm, may get a segmentation fault when forking a child to manage a new
display or X terminal.
- Xlib function XAddPixel may not work correctly when the format of the image
is ZPixmap and the visual is TrueColor.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (Patch ID: OSF350X-005) (Case ID: MGO101734, STLBA4448)
********
The X display manager, xdm, may get a segmentation fault when forking a child to
manage a new display or X terminal. Often this happens when managing the ninth
concurrent display on a system. The /usr/lib/X11/xdm/xdm-errors file will
contain messages similar to the following:
error (pid 2830): Unknown session exit code 2816 from process 2326
PROBLEM: (Case ID: TKTQ31025) (Patch ID: OSF350X-008)
********
The Xlib function XAddPixel may not work correctly when the format of the image
is ZPixmap and the visual is TrueColor. Some pixels may not be changed.
PROBLEM: ( SSRT0368U ) (Patch ID: OSF350X-015)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.
FILE(s):
/usr/bin/X11/xdm subset OSFX11350
CHECKSUM: 27695 128
/usr/lib/libX11.a subset OSFXDEV350
CHECKSUM: 17016 2020
/usr/lib/libXau.a subset OSFXDEV350
CHECKSUM: 64749 21
/usr/shlib/X11/libXau.so subset OSFSER350
CHECKSUM: 08206 32
/usr/shlib/X11/libos.so subset OSFX11350
CHECKSUM: 35354 128
/usr/shlib/libX11.so subset OSFX11350
CHECKSUM: 08330 1016
===============================================================================
Fixes the following problem: If the customer adds a new group with XSysAdmin
and then tries to use XIsso to add the user into the new group, the group shows
up but the user never gets added.
PROBLEM: ( MCPM5091F ) (Patch ID: OSF350X-019)
********
If the customer adds a new group with XSysAdmin and then tries to use XIsso to
add the user into the new group, the group shows up but the user never gets
added. If you add that group to the user profile and then save it (ok or apply)
and then pull up that user they are not part of the group.
FILE(s):
/usr/tcb/bin/XIsso subset OSFXC2SEC350
CHECKSUM: 42451 392
/usr/tcb/bin/XSysAdmin subset OSFXC2SEC350
CHECKSUM: 08340 368
===============================================================================
X server performance is slow when an application is drawing arcs which are
outside the bounds of the drawable window.
PROBLEM: (OSF_QAR 45015) (Patch ID: OSF350X-020)
********
X server performance is slow when an application is drawing arcs
which are outside the bounds of the drawable window.
FILE(s):
/usr/shlib/X11/libmi.so subset OSFX11350
CHECKSUM: 57636 296
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (QAR 47205) (Patch ID: OSF350X-021)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/lib/libXt.a subset OSFXDEV350
CHECKSUM: 03490 908
/usr/shlib/libXt.so subset OSFX11350
CHECKSUM: 27879 504
===============================================================================
Adds the new resource printOnlyPrintables to dxterm. When this resource is
set to TRUE (the default is FALSE), dxterm will not output any escape sequences
when printing. This is needed for some PostScript printer (filters) that can
not handle escape sequences.
PROBLEM: ( CLD TKTQA2401 ) (Patch ID: OSF350X-023)
********
When printing to a PostScript printer (or when using a print filter) that
does not understand ANSI escape sequences, the output contains extra,
unwanted characters. These are the actual, uninterpreted escape sequences.
This patch adds the new resource printOnlyPrintables to dxterm which can
be used to suppress ANSI escape sequences when printing.
To enable the new resource (and tell dxterm to not send escape sequences
to the printer) start dxterm as follows:
dxterm -xrm "*printOnlyPrintables: 1"
or add the following line to the dxterm resource file:
DXterm.main.terminal.printOnlyPrintables: 1
FILE(s):
/usr/bin/X11/dxterm subset OSFX11350
CHECKSUM: 14391 672
===============================================================================
- A potential security vulnerability has been discovered in bind, where
under certain circumstances users may gain unauthorized access.
Digital has corrected this potential vulnerability.
PROBLEM: (CLD-00805) (Patch ID: OSF350-348B)
********
A potential security vulnerability has been discovered in BIND
(Domain Name Service), where under certain circumstances,
system integrity may be compromised.
This may be in the form of improper file or privilege management.
Digital has corrected this potential vulnerability.
FILE(s):
/sbin/named subset OSFINET350
CHECKSUM: 10340 416
/usr/sbin/named subset OSFINET350
CHECKSUM: 16345 192
/usr/sbin/named-xfer subset OSFINET350
CHECKSUM: 03407 48 RCSfile: named-xfer.c RCS: 4.2.15.2
/usr/sbin/screend subset OSFINET350
CHECKSUM: 07819 312 RCSfile: screend.c RCS: 1.1.3.2
===============================================================================
Bookreader hangs when displaying certain pages if the required fonts are
not available. This problem usually occurs when redirecting Bookreader
display to another vendors workstation (HP or Sun).
PROBLEM: (MGO101893, HPXQ931C7) (Patch ID: OSF350X-025)
********
Bookreader hangs when displaying certain pages if the required fonts are
not available. This problem usually occurs when redirecting Bookreader's
display to another vendor's workstation (HP or Sun).
The correct behavior which this patch implements is to display an error
message indicating that the page may not be displayed correctly because
the required fonts are not available.
FILE(s):
/usr/bin/X11/dxbook subset OSFX11350
CHECKSUM: 22763 816
/usr/lib/X11/uid/DXBookreader_1_2.uid subset OSFX11350
CHECKSUM: 18153 164
===============================================================================
Fixes a problem that causes the system to panic after creating a symbolic link
to the root file system ('/') and accessing it like a normal file.
PROBLEM: (HPAQ83C24) (Patch ID: OSF350-297)
********
This patch fixes a problem that causes the system to panic after creating
a symbolic link to the root file system ('/') and accessing it like a
normal file.
For an AdvFS file system, the system will panic with the following error
message:
bs_bf_htop: invalid handle
For other file systems, the system will panic with the following error message:
vrele:bad ref count
For 'bs_bf_htop: invalid handle' (AdvFS) a typical stack trace could
look like:
0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1730]
1 panic(s = 0xffffffffa10f2e30 = "N1 = 0") ["../../../..
/src/kernel/bsd/subr_prf.c":757, 0xfffffc00004421e4]
2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":322, ]
3 bs_bf_htop() ["../../../../src/kernel/msfs/bs/bs_access.c":500, ]
4 bs_refpg() ["../../../../src/kernel/msfs/bs/bs_buffer2.c":1472, ]
5 seq_search() ["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1457, ]
6 msfs_lookup() ["../../../../src/kernel/msfs/osf/msfs_lookup.c":624, ]
7 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":563, ]
8 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2327, ]
9 stat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2295, ]
10 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
11 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]
For 'vrele:bad ref count' a typical stack trace could look like:
0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1730, ]
1 panic(s = 0xfffffc0000628238 = "vrele: bad ref count") ["../../..
/../src/kernel/bsd/subr_prf.c":757, 0xfffffc00004421e4]
2 vrele() ["../../../../src/kernel/vfs/vfs_subr.c":2196, ]
3 exit() ["../../../../src/kernel/bsd/kern_exit.c":875, ]
4 rexit() ["../../../../src/kernel/bsd/kern_exit.c":635, ]
5 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519, ]
6 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094, ]
FILE(s):
/usr/sys/BINARY/vfs_lookup.o subset OSFBIN350
CHECKSUM: 59330 10 RCSfile: vfs_lookup.c RCS: 4.2.63.2
===============================================================================
SUPERSEDES PATCH: OSF350-093 (93.00), OSF350-267 (267.00)
This patch corrects the following:
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
- On systems running enhanced security, the login process may fail
with a segmentation fault.
PROBLEM: (EVT101500) (Patch ID: OSF350-093)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0362U) (Patch ID: OSF350-267)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (HPAQ17931,HPAQA353A) (Patch ID: OSF350-298)
********
On systems running enhanced security, if the v_users keyword has been specified
for a device in the device assignment database (/etc/auth/system/devassign)
specifying the users that are permitted to login on that device, and a user
who is not on the v_users list attempts to login on that device, the login
process (login or xdm or dtlogin) will fail with a segmentation fault.
FILE(s):
/usr/shlib/libsecurity.so subset OSFBASE350
CHECKSUM: 31899 367
/usr/ccs/lib/libsecurity.a subset OSFC2SEC350
CHECKSUM: 39600 320
===============================================================================
This patch fixes a problem in which the ping command can time out after
invoking the "rcinet restart" command.
PROBLEM: (HPAQ88A35) (Patch ID: OSF350-301)
********
This patch fixes a problem in which the ping command can time out
after invoking the "rcinet restart" command.
To reproduce the problem:
1) Run the tcpdump utility on the lan interface and filter on ICMP traffic.
2) Stop and restart internet services using the command "rcinet restart".
You may have to restart services more than once to obtain an output
similar to the following while invoking the ping command;
10:25:50.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
10:25:51.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
10:25:52.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
10:25:53.802272 0.0.0.0 > 137.35.226.10: icmp: echo request
Notice the source field contains 0.0.0.0. The destination cannot return
the ICMP echo reply to this address. The ping command will timeout and
report 100% packet loss. The ping command can fail for a local destination
as well as a remote host.
FILE(s):
/sbin/init.d/route subset OSFCLINET350
CHECKSUM: 04095 3 RCSfile: route RCS: 1.1.14.2
===============================================================================
SUPERSEDES PATCH: OSF350-030 (30.00)
This patch corrects the following:
- Correct "siopintr: interrupt for non-initialized controller" boot error.
- Fixes a problem that occurs with the NCR 53C8XX driver (psiop) in which
the device may not appear to be on the SCSI bus.
PROBLEM: (QAR 36371) (Patch ID: OSF350-030)
********
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: (49240) (Patch ID: OSF350-302)
********
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_pci.o subset OSFHWBIN350
CHECKSUM: 00972 26 RCSfile: psiop_pci.c RCS: 1.1.30.2
/usr/sys/BINARY/psiop.o subset OSFHWBIN350
CHECKSUM: 33045 170 RCSfile: psiop.c RCS: 1.1.44.3
===============================================================================
SUPERSEDES PATCH: OSF350-178 (178.00)
This patch corrects the following:
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
- Fixes a problem that occurs in ASE/TCR environments in which the rpc.statd
daemon does not start when using the -p option to specify a long pathname
(> 45 characters). When this happens, NFS locking to the NFS service fails
causing applications like mail to hang.
PROBLEM: (SSRT0383U, QAR 45688) (Patch ID: OSF350-178)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (SOO100842, QAR 45974) (Patch ID: OSF350-304)
********
This patch fixes a problem that occurs in ASE/TCR environments in which
the rpc.statd daemon does not start when using the -p option to specify
a long pathname (> 45 characters). When this happens, NFS locking to the
NFS service fails causing applications like mail to hang.
FILE(s):
/usr/sbin/rpc.statd subset OSFNFS350
CHECKSUM: 50181 40
===============================================================================
SUPERSEDES PATCHES: OSF350-245 (245.00)
This patch corrects the following:
- On systems with PCXAL, LK411, and similar keyboards, after logging out of
a session on the workstation monitor, sometimes the keyboard stops working.
A reboot is required to clear the problem.
PROBLEM: (TKTQB1439,EVT101548,TPOBC2002,UVO103952) (Patch ID: OSF350-245)
********
On systems with PCXAL, LK411, and similar keyboards, after logging out of
a session on the workstation monitor, sometimes the keyboard stops working.
A reboot is required to clear the problem.
PROBLEM: (TKTB49381,GOZ100613,UTO101179) (Patch ID: OSF350-306)
********
On systems with PCXAL, LK411, and similar keyboards, after logging out of
a session on the workstation monitor, sometimes the keyboard stops working.
A reboot is required to clear the problem.
FILE(s):
/usr/sys/BINARY/pcxal.o subset OSFHWBIN350
CHECKSUM: 41294 19 RCSfile: pcxal.c RCS: 1.1.39.3
/usr/sys/BINARY/ws_device.o subset OSFHWBIN350
CHECKSUM: 39598 53 RCSfile: ws_device.c RCS: 1.2.46.2
===============================================================================
SUPERSEDES PATCH: OSF350-026 (26.00)
This patch corrects the following:
- Fixes a problem that could cause the system to panic displaying
the following panic string: "Simple_lock: hierarchy_violation."
- System panic with "simple_lock: time limit exceeded" message from vrele().
PROBLEM: (UVO103135) (Patch ID: OSF350-026)
********
This problem causes the panic:
`simple_lock: time limit exceeded` from vrele().
This can happen on multiple cpu systems where one cpu has a stack trace
which is similar to:
> 0 stop_secondary_cpu
1 panic
2 event_timeout
3 xcpu_puts
4 printf
5 procdup
6 newproc
7 fork1
8 fork
9 syscall
10 _Xsyscall
and another cpu has a stack trace similar to:
> 0 stop_secondary_cpu()
1 panic
2 event_timeout
3 xcpu_puts
4 printf
5 panic
6 simple_lock_fault
7 simple_lock_time_violation
8 vrele
9 vn_close
10 closef
11 close
12 syscall
13 _Xsyscall
PROBLEM: (QAR 46810) (Patch ID: OSF350-343)
********
This patch corrects a problem that can cause a system to panic
when performing intensive I/O.
An example of the stack trace follows:
...
...
_XentMM()
threads_get_rusage()
task_get_rusage()
fake_u()
table()
syscall()
_Xsyscall()
FILE(s):
/usr/sys/BINARY/vm_unix.o subset OSFBIN350
CHECKSUM: 31232 13 RCSfile: vm_unix.c RCS: 4.4.59.3
===============================================================================
SUPERSEDES PATCH: OSF350-187 (187.00), OSF350-226 (226.00)
This patch corrects the following:
- A problem exists with the atmarp command when you place a duplicate
entry in the ARP table. The system panics with a "kernel memory fault".
- There will be a panic from atm_arp when large arp caches are encountered.
- Prevents a panic that can occur after deleting an ATM ARP entry. The user
command to delete an ATM ARP entry is "atmarp -d". Subsequent access to the
ATM ARP table can cause the panic.
PROBLEM: ( KAOB17468 ) (Patch ID: OSF350-187)
********
A problem exists with the atmarp command when you place a duplicate
entry in the ARP table. The system panics with a "kernel memory fault".
tset machine_slot[paniccpu].cpu_panic_thread:
Begin Trace for machine_slot[paniccpu].cpu_panic_thread:
> 0 boot()["../../../../src/kernel/arch/alpha/machdep.c":1735]
1 panic() ["../../../../src/kernel/bsd/subr_prf.c":673,]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213,]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
4 ubc_flush_dirty() ["../../../../src/kernel/vfs/vfs_ubc.c":2946,]
5 mntflushbuf() ["../../../../src/kernel/vfs/vfs_bio.c":1427,]
6 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1664,]
7 panic() ["../../../../src/kernel/bsd/subr_prf.c":757,]
8 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213,]
9 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307,]
10 bcopy() ["../../../../src/kernel/arch/alpha/fastcopy.s":194,]
11 atm_arp_manage() ["../../../../src/kernel/netinet/atm/atm_arp.c":2709,]
12 atm_cmm_ioctl() ["../../../../src/kernel/io/atm/cmm/cmm_manage.c":145,]
13 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":1973,]
14 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1109]
15 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":465,]
16 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":344,]
17 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519,]
18 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094,]
End Trace for machine_slot[paniccpu].cpu_panic_thread:
PROBLEM: (QAR-45351) (Patch ID: OSF350-226)
********
There will be a panic from atm_arp when large arp caches are encountered.
PROBLEM: (HPXQB05E6) (Patch ID: OSF350-308)
********
This patch prevents a panic that can occur after deleting an ATM ARP entry
with the "atmarp -d" command.
Without this patch, the ATM ARP table can be left in an inconsistent state
if the ATM ARP entry deleted is the first entry in the table. Subsequent
access to the ATM ARP table can cause a panic.
FILE(s):
/usr/sys/BINARY/atm_arp.o subset OSFATMBIN350
CHECKSUM: 40052 138 RCSfile: atm_arp.c RCS: 1.1.31.5
===============================================================================
SUPERSEDES PATCHES: OSF350X-035 (398.00)
This patch corrects the following:
- Motif Text widget is afflicted with a memory leak. A small amount
of dynamic memory is lost each time the background colors in the widget
are changed.
- Motif applications may abort when you use the drag-and-drop feature.
PROBLEM: (USG-00572, QAR 51941) (Patch ID: OSF350X-035)
********
Motif applications may abort when you use the drag-and-drop feature.
Motif toolkit function XmCreateDragIcon() gets a "BadMatch (invalid
parameter attributes)" error and then crashes because the code fails
to set the correct image dimensions.
PROBLEM: (HPXQ64591 and STLQ60109) (Patch ID: OSF350X-038)
********
The Motif Text widget is afflicted with a memory leak. A small
amount of dynamic memory is lost each time the background colors
in the widget are changed.
FILE(s):
/usr/lib/libXm.a subset OSFXDEV350
CHECKSUM: 16430 4306
/usr/shlib/libXm.so subset OSFX11350
CHECKSUM: 03459 2440
===============================================================================
This patch fixes a problem that occurs when the system panics with the
following error message: kernel memory fault.
PROBLEM: (CLD HPAQC07YV) (Patch ID: OSF350-313)
********
This patch fixes a problem that occurs when the system panics
with the following error message:
kernel memory fault
The following is a typical stack trace of the system panic:
0 boot() [../../../../src/kernel/arch/alpha/machdep.c]
1 panic("kernel memory fault") [../../../../src/kernel/bsd/subr_prf.c]
2 trap() [../../../../src/kernel/arch/alpha/trap.c]
3 _XentMM() [../../../../src/kernel/arch/alpha/locore.s]
4 _svcauth_unix() [../../../../src/kernel/rpc/svc_auth_unix.c]
5 _authenticate() [../../../../src/kernel/rpc/svc_auth.c]
6 nfs_rpc_recv() [../../../../src/kernel/rpc/svc.c]
7 nfs_rpc_input() [../../../../src/kernel/rpc/svc.c]
8 nfs_input() [../../../../src/kernel/nfs/nfs_server.c]
9 nfs_thread() [../../../../src/kernel/nfs/nfs_server.c]
FILE(s):
/usr/sys/BINARY/svc_auth_unix.o subset OSFBIN350
CHECKSUM: 11247 6 RCSfile: svc_auth_unix.c RCS: 1.1.14.2
===============================================================================
This patch fixes a network socket problem with select() missing state changes
on clients from non-write to writable.
PROBLEM: (HPXQB6189/QAR 49949) (Patch ID: OSF350-317)
********
This patch fixes a network socket problem with select() missing state changes
on clients from non-write to writable.
FILE(s):
/usr/sys/BINARY/sys_socket.o subset OSFBIN350
CHECKSUM: 41983 7 RCSfile: sys_socket.c RCS: 4.3.32.2
===============================================================================
SUPERSEDES PATCHES: OSF350-090 (90.00)
This patch corrects the following:
- When using automated login for ftp with the help of a .netrc file,
the ACCOUNT FIELD information is not passed to the remote host.
- This patch fixes a problem with the ftp command. If you ftp to an IBM MVS
system using the IP address, the IBM system will refuse the connection.
This problem can be encountered on any system that validates TOS (Type Of
Service) requests if the file /etc/iptos is not used on the client.
PROBLEM: (MGO101812,QAR27629) (Patch ID: OSF350-090)
********
When using automated login for ftp with the help of a .netrc file,
the ACCOUNT FIELD information is not passed to the remote host.
How to recognize the problem; automated ftp login will fail to a server
that relies on ACCOUNT FIELD information in a users .netrc file.
Typical error messages will include "service not implemented".
PROBLEM: (MCPMC0L3C/QAR 50410) (Patch ID: OSF350-318)
********
This patch fixes a problem with the ftp command. If you ftp to an IBM MVS
system using the IP address, the IBM system will refuse the connection. This
problem can be encountered on any system that validates TOS (Type Of Service)
requests if the file /etc/iptos is not used on the client. It is recommended
that this patch be installed on all Digital UNIX systems.
How to recognize this problem:
If you attempt to ftp to any system that validates TOS requests, you may
see the following:
ftp> open
Connected to
220-FTPSERV1 IBM MVS V3R1 at SAC1, 12:08:49 on 1996/12/11
421 Service not available, remote server has closed connection
but it may work if you give the hostname of the system instead of the
ip address.
If you were running tcpdump, tracing the connection, you would see
12:26:20.076128 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: S
1419648000:1419648000(0)
win 32768 (DF)
12:26:20.176656 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: S
447244900:447244900(0)
ack 1419648001 win 65535
12:26:20.176656 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 1 win 33580 (DF)
12:26:20.274256 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: P
1:60(59) ack 1 win 65535
12:26:20.366000 irvingirving.cxo.dec.com.2296 > mvssac1.rac.mci.com.ftp: .
ack 60 win 33580 (DF)
[tos 0xa6] <<<<<----NOTICE THIS!!!
12:26:20.461648 mvssac1.rac.mci.com.ftp > irvingirving.cxo.dec.com.2296: R
447244960:447244960(0) win 0
In the above trace, the connection is rejected because the TOS (Type Of Service)
field contains an invalid value. This problem can be avoided by using a
/etc/iptos file as noted in the man page. However, the TOS field should never
have this invalid value and that is the reason for the patch.
FILE(s):
/usr/bin/ftp subset OSFCLINET350
CHECKSUM: 01413 136 RCSfile: ftp.c RCS: 4.2.20.3
===============================================================================
SUPERSEDES PATCHES: OSF350-002 (2.00), OSF350-075 (75.00),
OSF350-261 (261.00)
This patch corrects the following:
- Stray interrupts which lock up the PCI bus and hang the system.
- Reseating disks in BA356 off P2SE would cause the slot to become inaccessible.
- All Alpha/PCI systems that support QLogic fail to boot when two or more tapes
are installed on a QLogic/SCSI channel.
- Panics:
o simple lock time limit exceeded
o unable to restart Qlogic(LUN queue after abort)
o simple_unlock: minimum spl violation
- "CAM_ERROR entry too large" messages.
- ASE: Qlogic driver returns incorrect status if the sim driver is unable to
correctly respond to an Enable_Lun command from the peripheral driver.
- CAM errors when the target NVRAM parameters for either tagged queueing or
disconnect privilege enable are disabled.
- Data transfer size of 16Mb results in no data transferred.
- Probe of isp fails intermittently during boot.
The following driver corrections require hardware changes to fully resolve
the noted problems:
- pcierror panic. These driver changes might help mitigate the occurrence of
this panic. Complete solution of the problem will involve some changes in
the Tlaser platform code.
- Bus Device Resets on narrow or wide SCSI devices. Complete solution of these
problems requires both this modified driver and new Qlogic firmware
(rev 2.10 or greater).
- Data corruption occurs on SCSI write transaction in response to a particular
sequence of events on the PCI and SCSI bus. This driver change, in
combination with rev 2.10 or greater Qlogic firmware, corrects the problem.
PROBLEM: (Patch ID: OSF350-002) (QAR 32284)
********
Certain conditions could cause stray interrupts which lock up the PCI bus,
hanging the system.
PROBLEM: (Patch ID: OSF350-002) (QAR 33107)
********
Re-seating RZ28M/RZ28VW/RZ26N in BA356 off P2SE would cause the slot
to become inaccessible, which would require a reboot to regain access
to the slot.
PROBLEM: (Patch ID: OSF350-002) (QAR 35448)
********
All Alpha/PCI systems that support QLogic fail to boot when two or more tapes
are installed on a QLogic/SCSI channel. The system hangs during boot.
PROBLEM: (Patch ID: OSF350-075) (Case ID: QAR 32939)
********
System panics after 24 hours with "simple_lock: time limit exceeded". Problem
occurs when Qlogic driver calls zfree() to free allocated memory when in
interrupt context.
Panic will occur with panic string "simple_lock: time limit exceeded".
The full stack trace is as follows:
1 panic("event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf.c":673]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":698]
3 simple_lock_miss() ["../../../../src/kernel/arch/alpha/lockprim.s":1062]
4 zfree() ["../../../../src/kernel/kern/zalloc.c":713]
5 cam_zfree() ["../../../../src/kernel/io/cam/sim_common.c":1424]
6 sc_free() ["../../../../src/kernel/io/cam/sim_common.c":1222]
7 isp_process_response_queue() ["../../../../src/kernel/io/cam/qlogic/isp1020.c":2421]
8 isp_intr() ["../../../../src/kernel/io/cam/qlogic/isp1020.c":2040]
9 _XentInt() ["../../../../src/kernel/arch/alpha/locore.s":926]
10 swap_ipl() ["../../../../src/kernel/arch/alpha/spl.s":131]
11 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1554]
12 panic() ["../../../../src/kernel/bsd/subr_prf.c":757]
13 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":1601]
14 simple_lock_time_violation() ["../../../../src/kernel/kern/lock.c":1670]
15 zfree() ["../../../../src/kernel/kern/zalloc.c":713]
16 cam_zfree() ["../../../../src/kernel/io/cam/sim_common.c":1424]
17 sc_free() ["../../../../src/kernel/io/cam/sim_common.c":1222]
18 isp_process_response_queue() ["../../../../src/kernel/io/cam/qlogic/isp1020.c":2421]
19 isp_intr() ["../../../../src/kernel/io/cam/qlogic/isp1020.c":2040]
20 _XentInt() ["../../../../src/kernel/arch/alpha/locore.s":926]
21 simple_lock_B() ["../../../../src/kernel/arch/alpha/lockprim.s":505]
22 zfree() ["../../../../src/kernel/kern/zalloc.c":713]
23 cam_zfree() ["../../../../src/kernel/io/cam/sim_common.c":1424]
24 ccmn_rel_dbuf() ["../../../../src/kernel/io/cam/pdrv_common.c":3297]
25 cdisk_online() ["../../../../src/kernel/io/cam/cam_disk.c":2130]
26 cdisk_open() ["../../../../src/kernel/io/cam/cam_disk.c":1790]
27 spec_open() ["../../../../src/kernel/vfs/spec_vnops.c":1280]
28 get_raw_vd_attrs() ["../../../../src/kernel/msfs/bs/bs_domain.c":1420]
29 bs_bfdmn_tbl_activate() ["../../../../src/kernel/msfs/bs/bs_domain.c":613]
30 fs_fset_get_info() ["../../../../src/kernel/msfs/fs/fs_file_sets.c":626]
31 msfs_real_syscall() ["../../../../src/kernel/msfs/bs/bs_misc.c":2622]
32 msfs_syscall() ["../../../../src/kernel/msfs/osf/msfs_syscalls.c":122]
33 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":530]
34 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1086]
PROBLEM: (Patch ID: OSF350-075) (Case ID: QAR 34634)
********
System running intensive Oracle Queries in asynchronous I/O mode on Tlaser/KFTIA
using raw device on top of LSM volumes crashes with pciaerror panic.
This modified driver, by itself, cannot totally eliminate the occurrence of
this panic, but several of the driver changes might help mitigate the occurrence
of this panic. Complete solution of the problem will involve some changes in the
Tlaser platform code.
PROBLEM: (Patch ID: OSF350-075) (Case ID: QAR 36319)
********
Running Bus Device Reset test scripts on narrow or wide SCSI devices results
in timeouts, aborts, hung SCSI buses, UBC write errors and dirty file systems.
This problem would be exhibited on all platforms.
Complete solution of these problems requires both this modified driver and new
Qlogic firmware (rev 2.10 or greater).
PROBLEM: (Patch ID: OSF350-075) (Case ID: QAR 38014)
********
In the Available Server Environment, the Qlogic driver returns incorrect
status if the sim driver is unable to correctly respond to an Enable_Lun
command from the peripheral driver. This occurs if an Enable_Lun is attempted
to an adapter that contains the Qlogic 1020 chip (minimum chip rev is the
1020A). This results in error messages being printed on the system console.
The error message is of the form:
vmunix: isp_enable_target failed: status=0x4001
PROBLEM: (Patch ID: OSF350-075) ( No CLD, QAR or SPR)
********
CAM errors when the target NVRAM parameters for either tagged queueing or
disconnect privilege enable are disabled.
PROBLEM: (Patch ID: OSF350-075) (No CLD, QAR or SPR).
********
Specifying a data transfer size of 16Mb results in no data transferred on
the SCSI bus.
PROBLEM: (Patch ID: OSF350-075) ( No CLD, QAR or SPR).
********
Data corruption occurs on SCSI write transaction in response to a particular
sequence of events on the PCI and SCSI bus. This driver change, in combination
with rev 2.10 or greater Qlogic firmware, corrects the problem.
Problem exists in either the 1020 or 1020A chip.
PROBLEM: ( TKTB52828, QAR 42761 ) (Patch ID: OSF350-261)
********
This patch fixes the following system panic:
panic `Unable to restart Qlogic(LUN queue after abort)
A typical stack trace for this type of panic is:
0 boot
1 panic `Unable to restart Qlogic(LUN queue after abort)`
2 isp_termio_abort_bdr
3 ss_perform_abort
4 ss_sched
5 scsiisr
6 ss_start_sm
7 ss_go
8 ss_abort
9 ss_perform_timeout
10 ss_process_timeouts
11 softclock_scan
12 hardclock
13 _XentInt
14 idle_thread
PROBLEM: ( QAR 46071, 45122 ) (Patch ID: OSF350-261 )
********
This patch fixes the following system panic:
simple_unlock: minimum spl violation
pc of caller: 0xfffffc0000420b04
lock address: 0xfffffc0077f236d0
lock info addr: 0xfffffc00005b0b50
lock class name: cam_pd_device (could also be cam_isp)
current spl level: 0
required spl level: 4
panic (cpu xx): simple_unlock: minimum spl violation
where 'xx' above is the CPU number. A sample stack trace is not available.
This panic is seen when lockmode is set to 4.
PROBLEM: ( QAR 46756 ) (Patch ID: OSF350-261 )
********
This patch fixes the situation where the following sequences of messages are
displayed during startup:
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_enable_lun
Failed to enable target for selections
cam_logger: CAM_ERROR entry too large to log!
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_enable_lun
Failed to enable target for selections
cam_logger: CAM_ERROR entry too large to log!
cam_logger: CAM_ERROR packet
PROBLEM: ( ZPOB71272, 46139, 46757, 42908, 43719, 44474, 40361, 40443,41465)
******** ( Patch ID: OSF350-261 )
This patch fixes the following system panic:
panic `Simple lock : time limit exceeded`
One typical stack trace for this type of panic is:
4 boot
5 panic
6 simple_lock_fault
7 simple_lock_time_violation
8 ss_finish
9 sm_bus_free
10 isp_process_response_queue
11 isp_intr
12 intr_dispatch_post
13 _XentInt
14 isp_mailboxcomplete
15 isp_mailboxissue
16 isp_abort
17 isp_termio_abort_bdr
18 ss_perform_abort
19 ss_sched
20 scsiisr
Another stack trace encountered is:
12 boot
13 panic `Simple lock : time limit exceeded`
14 simple_lock_fault
15 simple_lock_time_violation
16 ss_finish
17 ss_abort_done
18 sm_bus_free
19 isp_abort_done
20 softclock_scan
21 hardclock
22 _XentInt
23 alpha_delay
24 microdelay
25 isp_mailboxcomplete
26 isp_mailboxissue
27 isp_stop_queue
28 isp_termio_abort_bdr
29 ss_perform_abort
30 ss_sched
31 scsiisr
32 ss_start_sm
33 ss_go
34 ss_abort
PROBLEM: (HGOBB0043,HGOBB0597) (Patch ID: OSF350-320)
********
Intermittently, the probe of an isp will fail during a boot, and the system can
hang. This happens maybe once in 20 system boots, so a workaround is to try
the boot again.
A typical console listing looks like this when it fails:
.
.
.
Created FRU table configuration errorlog packet
tiop0 at tlsb0 node 8
tiop0: cpu interrupt mask being set as 1.
pci0 at tiop0 slot 0
isp0 at pci0 slot 0
isp0: QLOGIC ISP1020 - Differential Mode
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_mailbox complete
Timeout on mailbox command completion scheduling chip reinit
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_init
Mailbox operations not functional for common init
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_probe
Common init failure - Failing probe
isp0: Not probed.
isp in slot 0 not configured.
.
.
.
IMPORTANT: This patch should be installed on ANY system that contains
a Qlogic chip. If the system boot sequence displays the
word "Qlogic", then install this patch. Qlogic chips are built
into many systems, and can also be found in many add-on options,
such as: KFTIA, KZPBA, KZPDA, PZPSM, P1SE, P2SE, and others.
FILE(s):
/usr/sys/BINARY/isp1020.o subset OSFHWBIN350
CHECKSUM: 63985 88 RCSfile: isp1020.c RCS: 1.1.36.5
/usr/sys/include/io/cam/qlogic/isp1020.h subset OSFBINCOM350
CHECKSUM: 44553 43 RCSfile: isp1020.h RCS: 1.1.28.4
===============================================================================
SUPERSEDES PATCHES: OSF350-140 (140.00)
This patch corrects the following:
- The terminal line characteristics for telnet with a modem were being reset
to 7-bits/no-parity from 8-bits/no-parity.
- A problem where telnet dumps core if the USER environment variable is the
last variable in the enviroment list.
PROBLEM: (HPAQ26C0B, QAR 43433) (Patch ID: OSF350-140)
********
The terminal line characteristics for telnet with a modem were being reset
to 7-bits/no-parity from 8-bits/no-parity.
How to recognize the problem:
If you have an application that requires you to specify 8 bits/no-parity
for use with serial terminals and dial-in modems, telnet will override
the setting giving you 7 bits/no-parity. Check the terminal settings
with the command stty -a.
You typically would see the following:
parenb -parodd cs7 -cstopb hupcl cread -clocal
when you really want:
-parenb -parodd cs8 -cstopb hupcl cread -clocal
PROBLEM: (FNO100131, QAR 43995) (Patch ID: OSF350-322)
********
This patch fixes a problem where telnet dumps core if the USER environment
variable is the last variable in the enviroment list.
FILE(s):
/usr/bin/telnet subset OSFCLINET350
CHECKSUM: 11837 128 RCSfile: commands.c RCS: 4.2.19.2
===============================================================================
SUPERSEDES PATCHES: OSF350X-004 (314.00), OSF350X-010 (320.00),
OSF350X-012 (322.00), OSF350X-016 (326.00)
PCI Hardware ATI Mach 64 Graphics CX, GX, & CT Corrections:
- ATI Mach64 graphics family (e.g. GX, CX, and CT) (PB2GA-FA) problems
o Poor performance during PolyFillSolid operations frequently used
by applications such as Netscape
o Multi-screen problems when using 2 ATI Mach64 CX graphics cards on
an Alphastation 400
o Dashed lines with a line style of LineOnOffDash are too short
o Sometimes the monitor will lose synchronization or become stuck
in power-save mode.
- S3 Trio64 graphics card problems
o The first character of the user name is ignored during login.
o A cursor warped by software is not recognized by the kernel.
o A FillSolid operation with a negative starting point is not
always clipped correctly.
o Screen "noise" occurs when using resolutions other than 1024x768.
PROBLEM: (Patch ID: OSF350X-004)
********
The ATI Mach64 graphics family (e.g. GX, CX, and CT) (PB2GA-FA) becomes bogged
down during PolyFillSolid operations frequently used by applications such as
Netscape. This results in poor performance and the reporting of hundreds of
lines per operation in the /var/X11/xdm/xdm-errors file which could eventually
fill the /var partition.
PROBLEM: (QAR 37037,35476,35481, GRP-00051) (Patch ID: OSF350X-004)
********
This patch fixes the following problems with the S3 Trio64 graphics card:
o The first character of the user name is ignored during login.
o A cursor warped by software is not recognized by the kernel.
o A FillSolid operation with a negative starting point is not always clipped
correctly.
o Screen "noise" occurs when using resolutions other than 1024x768.
PROBLEM: (Case ID: MGO101857) (Patch ID: OSF350X-010)
********
Dashed lines with a line style of LineOnOffDash are too short when displayed on
an ATI Mach64 graphics option.
PROBLEM: (QAR 42672) (Patch ID: OSF350X-012)
********
On a system with an S3 Trio64 graphics card set at a resolution of 1280x1024,
the cursor does not display correctly.
PROBLEM: (MGO102057) (Patch ID: OSF350X-016)
********
On an AlphaStation 400 with two ATI Mach64 CX graphics cards (dual-screen),
the display on the second screen is corrupted at 1280x1024 resolution.
PROBLEM: (TKTB71151,TKTB64248) (Patch ID: OSF350X-032)
********
On systems with an ATI Mach64 graphics card, sometimes the monitor will
lose synchronization or become stuck in power-save mode.
FILE(s):
/usr/shlib/X11/lib_dec_ati64.so subset OSFSERPCI350
CHECKSUM: 32895 128 RCSfile: atiio.c RCS: 1.1.17.3
/usr/shlib/X11/lib_dec_s3.so subset OSFSERPCI350
CHECKSUM: 37153 144 RCSfile: s3curs.c RCS: 1.1.13.3
RCSfile: s3io.c RCS: 1.1.17.3
RCSfile: s3polys.c RCS: 1.1.11.2
RCSfile: s3init.c RCS: 1.1.13.2
===============================================================================
SUPERSEDES PATCH: OSF350-070 (70.00), OSF350-214 (214.00)
This is a MANDATORY patch for all machines containing the DECchip 21040-AA and
DECchip 21041-AA (TULIP) Ethernet chips.
This patch corrects the following:
- Under relatively rare and stressful conditions, the DE500-XA Fast Ethernet
interface (tu) will stop receiving packets. This causes the interface to
appear hung.
- Under certain relatively rare and stressful conditions, the DECchip 21040-AA
and DECchip 21041-AA (TULIP) Ethernet chips will corrupt a transmit packet and
compute/create the CRC per the corrupted data and send the corrupted packet.
- Under heavy system/bus loads, the default programming of the DECchip 21140-AA
Fast Ethernet device (DE500), results in excessive framing errors.
- Under relatively rare and stressful conditions, the DE500-XA Fast Ethernet
interface (tu) will stop receiving packets.
- Fixes a system panic, on a SMP system and tu interface, with error message:
System Uncorrectable Machine Check 660 (retry set)
PROBLEM: (Patch ID: OSF350-070) (QAR 39571)
********
Under certain relatively rare and stressful conditions, the DECchip 21040-AA
and DECchip 21041-AA (TULIP) Ethernet chips will corrupt a transmit packet and
compute/create the CRC per the corrupted data and send the corrupted packet.
The DECchip 21040-AA is embedded in various AlphaStations, AlphaServers, and
Alpha Single Board Computers. This device is also used on various PCI and EISA
network options such as the DE434, DE435, DE436, and DE425.
The DECchip 21041-AA is only used on the DE450 PCI Ethernet options.
PROBLEM: (Patch ID: OSF350-070) (HPXQ92E27)
********
Under heavy system/bus loads, the default programming of the DECchip 21140-AA
Fast Ethernet device (DE500), results in excessive framing errors. In the
worst case, the error rate is so high that performance is better with a
regular 10 Mbps Ethernet for performing similar types of network activity.
PROBLEM: (QAR 45779) (Patch ID: OSF350-214)
********
Under relatively rare and stressful conditions, the DE500-XA Fast Ethernet
interface (tu) will stop receiving packets. This causes the interface to
appear hung. However, there's no explicit indication of this state at the
user level. The only way out of this state is to restart the network.
PROBLEM: (CLD SOO100882) (Patch ID: OSF350-330)
********
This patch fixes a problem that occurs on an SMP system with a
tu (Tulip) Ethernet interface.
The system panics with the following error message:
System Uncorrectable Machine Check 660 (retry set)
FILE(s):
/usr/sys/include/io/dec/netif/if_tureg.h subset OSFBINCOM350
CHECKSUM: 47863 17
/usr/sys/data/if_tu_data.c subset OSFBINCOM350
CHECKSUM: 14161 6 RCS: 1.1.30.2
/usr/sys/BINARY/if_tu.o subset OSFHWBIN350
CHECKSUM: 01548 36 RCSfile: if_tu.c RCS: 1.1.56.4
===============================================================================
SUPERSEDES PATCHES: OSF350-254 (254.00)
This patch corrects the following:
- Fixes a problem in which mail cannot be sent to usernames consisting of
uppercase and lowercase letters, for example, FooBar.
- Fixes a problem in which mail fails when either of the following conditions
occurs:
o A Large distribution list is used.
o A distribution list contains more than 1024 characters.
- Error in Sending mail get both mail and error messages where the error
messages do not correctly describe problem.
- sendmail command loops endlessly trying to get a "tf" control file in
/var/spool/mqueue.
- A potential security vulnerability has been discovered with the sendmail
command, where under certain circumstances, users may gain unauthorized
access. Digital has corrected this potential vulnerability.
PROBLEM: (HPXQ36202) (Patch ID: OSF350-254)
********
This patch fixes a problem in which mail cannot be sent to usernames consisting
of uppercase and lowercase letters, for example, FooBar.
PROBLEM: (HPXQ22677) (Patch ID: OSF350-254)
********
This patch fixes a problem in which mail fails when either of the following
conditions occurs:
o A Large distribution list is used.
o A distribution list contains more than 1024 characters.
PROBLEM: (HPAQ69EDF, QAR 29063) (Patch ID: OSF350-331)
********
If the user sending mail makes an error entering the address of the person
they are sending mail to, they will receive a mail message that contains both
the text of their mail and the error messages.
The error messages do not correctly describe the exact nature of the problem.
For example:
The "RCPT TO:" address line is entered as the user
The "To:" address line is mistakenly entered as the user <"bozo>.
The error messages will be displayed as follows:
554 Unbalanced '<'
050 ... Connecting to (local)...
554 ... Unbalanced '<'
554 ... Unbalanced '<'
050 ... Sent
554 Unbalanced '<'
554 Unbalanced '<'
PROBLEM: (HPAQ85B98, QAR 41131) (Patch ID: OSF350-331)
********
Fixes a problem in which the sendmail command loops endlessly trying to get a
"tf" control file in /var/spool/mqueue.
PROBLEM: (SSRT0421U, QAR 49337) (Patch ID: OSF350-331)
********
A potential security vulnerability has been discovered with the sendmail
command, where under certain circumstances, users may gain unauthorized access.
Digital has corrected this potential vulnerability.
FILE(s):
/usr/sbin/mailq subset OSFBASE350
CHECKSUM: 55032 208
/usr/sbin/newaliases subset OSFBASE350
CHECKSUM: 55032 208
/usr/sbin/sendmail subset OSFBASE350
CHECKSUM: 55032 208
/usr/sbin/smtpd subset OSFBASE350
CHECKSUM: 55032 208
/usr/var/adm/sendmail/.mrg..sendmail.cf subset OSFBASE350
CHECKSUM: 46196 4
/usr/var/adm/sendmail/.new..sendmail.cf subset OSFBASE350
CHECKSUM: 57336 21
===============================================================================
A system that boots and runs OK with 3 DE425s on an eisa bus may hang during
boot if a 4th DE425 is added to the bus.
If a device's EISA configuration file contains a function DISABLE keyword and
the DISABLE option is selected, the device's driver may not be configured and
probed at bus configuration time.
PROBLEM: (EVT101968) (Patch ID: OSF350-334)
********
A system that boots and runs with three DE425 adapters off an EISA bus may hang
during the boot operation if a fourth DE425 adapter is added to the bus.
Just before the system hangs, the system displays a message similar
to the following:
eisa at pci0
The system will not respond to the halt button.
PROBLEM: (Patch ID: OSF350-334)
********
If a device's EISA configuration file contains a function DISABLE keyword
and the DISABLE option is selected, the device's driver may not be configured
and probed at bus configuration time.
FILE(s):
/usr/sys/BINARY/eisa_cnfg.o subset OSFHWBIN350
CHECKSUM: 25437 13 RCSfile: eisa_cnfg.c RCS: 1.1.41.2
===============================================================================
SUPERSEDES PATCH: OSF350-160 (160.00), OSF350-300 (338.00)
This patch corrects the following:
- Fixes a security issue in which a user using anonymous ftp could be logged in
to the root directory.
- ftpd core dumps when using anonymous ftp with the ls commmand.
- A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file or privilege management. Digital has
corrected this potential vulnerability.
PROBLEM: ( HPXQ917BA ) (Patch ID: OSF350-160)
********
This patch fixes a security issue in which a user using anonymous ftp could be
logged in to the root directory.
If the home directory of 'ftp' (used for anonymous ftp) does not exist, or
is otherwise inaccessible to the 'ftp' user, then a user logging in via
anonymous ftp is logged in with a home directory of '/'.
Arrange for the home directory of the 'ftp' user to be inaccessible (by
renaming it to something else, for instance), then from ftp try logging into
the system with anonymous ftp. If the login is successful and the user has
/ for their home directory, the bug exists.
PROBLEM: (QAR 48194) (Patch ID: OSF350-300)
********
When doing an ls in an ftp session and when current directory is under a
directory with execute-only permissions, ftpd was core dumping while trying to
generate a syslog entry.
PROBLEM: (SSRT0448U, QAR 51211) (Patch ID: OSF350-335)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.
FILE(s):
/usr/sbin/ftpd subset OSFCLINET350
CHECKSUM: 02385 96 RCSfile: ftpd.c RCS: 4.2.28.4
RCSfile: ftpd_syslog.c RCS: 1.1.2.2
===============================================================================
SUPERSEDES PATCH: OSF350-105 (105.00)
This patch corrects the following:
- Applications linked with DECthreads will behave as if they have
no more memory available to them when they are not even close
to the operating system limit.
- Corrects a problem where multi-threaded applications will experience a hang
on SMP systems.
PROBLEM: (MGO101698) (Patch ID: OSF350-105)
********
Applications linked with DECthreads will behave as if they have no more
memory available to them when they are not even close to the operating system
limit.
PROBLEM: (MGO102540) (Patch ID: OSF350-336)
********
Multi-threaded applications may end up hanging on SMP systems. This will occur
when a mutex, central to the application's operation, is left locked by the
DECthreads library. There is no work around to this problem.
FILE(s):
/usr/ccs/lib/libpthreads.a subset OSFPGMR350
CHECKSUM: 52551 439 RCSfile: cma_vm.c RCS: 4.2.20.2
/usr/include/dce/exc_handling.h subset OSFPGMR350
CHECKSUM: 33034 30 RCSfile: exc_handling.h RCS: 4.2.16.2
/usr/shlib/libpthreads.so subset OSFBASE350
CHECKSUM: 34268 576 RCSfile: cma_vm.c RCS: 4.2.20.2
===============================================================================
SUPERSEDES PATCHES: OSF350-347 (393.00), OSF350-347-1 (393.01)
This patch corrects the following:
- Fixes fsck operation where if fsck is run on a non-existent file system
or on a currently mounted file system, it returns a success status of zero.
It should return a non-zero status.
- Fixes a problem in which the UFS property list can become corrupted.
PROBLEM: (QAR 46424) (Patch ID: OSF350-347-1)
********
This patch fixes a problem in which the UFS property list can become corrupted.
To reproduce this problem, complete the following steps:
1. Create a relatively large property value on a file.
2. Create another property value on the same file.
3. Change the property value created in Step 1 to a smaller value.
4. Run fsck with the -o flag.
The fsck command reports that the file system is corrupted and displays
the following error message:
** Phase 1 - Check Blocks and Sizes
PROPERTY LIST BLOCK CORRUPTED I=3
CLEAR? [yn]
PROBLEM: (QAR 50363) (Patch ID: OSF350-357)
********
This patch fixes a problem with the fsck command. When fsck is run
on a non-existent file system or on a currently mounted file system,
it returns a success status of zero. It should return a non-zero status.
An example where this problem is exhibited is shown here:
# fsck /dev/rrz6c
/sbin/ufs_fsck /dev/rrz6c
** /dev/rrz6c
BAD SUPER BLOCK: MAGIC NUMBER WRONG
/dev/rrz6c: NOT LABELED AS A BSD FILE SYSTEM (swap)
# echo $?
0
ALSO:
# fsck /mnt
/sbin/ufs_fsck /mnt
Can't make sense out of name /mnt
# echo $?
0
FILE(s):
/sbin/ufs_fsck subset OSFBASE350
CHECKSUM: 07473 328 RCSfile: main.c RCS: 4.3.36.2
RCSfile: setup.c RCS: 4.3.33.2
RCSfile: utilities.c RCS: 4.3.18.2
RCSfile: preen.c RCS: 4.3.30.2
/usr/sbin/ufs_fsck subset OSFBASE350
CHECKSUM: 44660 112 RCSfile: inode.c RCS: 4.3.25.2
RCSfile: main.c RCS: 4.3.36.2
RCSfile: setup.c RCS: 4.3.33.2
RCSfile: utilities.c RCS: 4.3.18.2
RCSfile: preen.c RCS: 4.3.30.2
/usr/sys/BINARY/ufs_proplist.o subset OSFBIN350
CHECKSUM: 13047 22 RCSfile: ufs_proplist.c RCS: 1.1.42.2
===============================================================================
Fixes a problem in which the dd command can corrupt output on very large files
(2 GB or greater) when the "conv=sparse" option is used.
PROBLEM: (QAR 47063) (Patch ID: OSF350-359)
********
This patch fixes a problem in which the dd command can corrupt output on
very large files (2 GB or greater) when the "conv=sparse" option is used.
In some cases a seek error is reported:
dd seek error: Invalid argument
In other cases a corrupt file is created with no error reported.
FILE(s):
/sbin/dd subset OSFBASE350
CHECKSUM: 00499 496 RCSfile: inet_addr.c RCS: 4.2.22.2
RCSfile: dd.c RCS: 4.3.29.2
/usr/bin/dd subset OSFBASE350
CHECKSUM: 02278 496 RCSfile: inet_addr.c RCS: 4.2.22.2
RCSfile: dd.c RCS: 4.3.29.2
===============================================================================
Fixes an error that occurs when replying to a message in which the "CC:" field
contains blank-separated names not enclosed in angle brackets ("<...>").
PROBLEM: (UVO105070, QAR 50239) (Patch ID: OSF350-362)
********
An error occurs when replying to a message in which the "CC:" field contains
blank-separated names not enclosed in angle brackets ("<...>").
When replying to mail using lowercase "r", the "CC:" field on the reply
lists all blank-separated names after all enclosed angle bracket addresses.
The following error message is displayed:
... User unknown
FILE(s):
/usr/bin/mailx subset OSFBASE350
CHECKSUM: 09433 208
/usr/bin/Mail subset OSFBASE350
CHECKSUM: 09433 208
===============================================================================
Fixes problem where exiting from the DECwindows Session Manager (dxsession)
via the 'Close' option of the window menu results in an undesirable saving
of dxsession's scratch file in /tmp. Use of this button also causes
a behavior inconsistent, with dxsession's 'End Session' button.
PROBLEM: (HPAQ210HY) (Patch ID: OSF350X-033)
********
When exiting from the DECwindows Session Manager (dxsession) via
the 'Close' option of the window menu results in an undesirable saving
of dxsession's scratch file in /tmp. Use of this button also causes
a behavior inconsistent, with dxsession's 'End Session' button.
FILE(s):
/usr/bin/X11/dxsession subset OSFX11350
CHECKSUM: 58324 232
===============================================================================
SUPERSEDES PATCHES: OSF350-008 (8.00)
This patch corrects the following:
- Fixes the pipe function, occurs primarily on SMP systems,
that exits prematurely causing data errors.
- Processes can hang and/or become defunct when using fnctl() operation
on pipes.
PROBLEM: (HPXQ71268) (Patch ID: OSF350-008)
********
Processes that do fcntl() operations on pipes will sometimes hang when trying
to exit or become zombies (defunct processes). Customers using Interleaf are
strongly urged to apply this patch.
PROBLEM: (QAR 46316,37041/7NSB13773/TKTB14933) (Patch ID: OSF350-370)
********
This patch fixes a problem with the pipe function that occurs
primarily on SMP systems. The pipe function exits prematurely
causing data errors and does not produce the expected results.
FILE(s):
/usr/sys/BINARY/fifo_vnops.o subset OSFBIN350
CHECKSUM: 10440 73 RCSfile: fifo_vnops.c RCS: 4.3.44.3
===============================================================================
SUPERSEDES PATCH: OSF350-032 (32.00), OSF350-165 (165.00)
- Attempting to write to a TKZ15 tape drive using compression mode resulted
in an error which prevents the drive from being written to.
- Fixes "simple_lock: time limit exceeded" panics coming from ctape_close() and
ctape_strategy() routines.
- Fixes "simple_lock: time limit exceeded".
PROBLEM: (Patch ID: OSF350-032) (QAR 36933)
********
Attempting to write to a TKZ15 tape drive using compression mode resulted
in an error which prevents the drive from being written to.
PROBLEM: ( MCPM36085,UVO104133 ) (Patch ID: OSF350-165)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the
ctape_close() routine in the cam tape subsystem.
The stack trace of the panicing process is as follows:
6 panic(s = 0xfffffc0000618890 = "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: ( MCPM36085,UVO104133 ) (Patch ID: OSF350-165)
********
A "simple_lock: time limit exceeded" panic will be seen originating from the
ctape_strategy() routine in the cam tape subsystem.
The stack trace of the panicing process is as follows:
9 panic(s = 0xfffffc00005b1650 = "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: OSF350-341)
********
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 266)
(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 266)
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_prf.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 OSFHWBIN350
CHECKSUM: 45317 146 RCSfile: cam_tape.c RCS: 1.1.42.4
===============================================================================
A potential security vulnerability has been discovered in talkd,
where under certain circumstances, system integrity may be
compromised. Digital has corrected this potential vulnerability.
PROBLEM: (SSRT0446U) (Patch ID: OSF350-351)
********
A potential security vulnerability has been discovered in talkd,
where under certain circumstances, system integrity may be
compromised. Digital has corrected this potential vulnerability.
FILE(s):
/usr/sbin/talkd subset OSFCLINET350
CHECKSUM: 04810 32 RCSfile: talkd.c RCS: 4.2.6.2
/usr/sbin/ntalkd subset OSFCLINET350
CHECKSUM: 04810 32
===============================================================================
SUPERSEDES PATCH: OSF350-099 (99.00), OSF350-164 (164.00)
This patch corrects the following:
- Fixes a panic caused by a "simple lock: time limit exceeded".
- When running tape tests on a KZTSA SCSI adapter a data corruption problem
was found. This data corruption is only seen on large (> 1Meg) odd byte
transfers. It can occur on any tape drive connected to the KZTSA SCSI adapter.
- Infrequently, under heavy disk I/O loads, user data can be
written to the wrong disk, resulting in data corruption.
- When a tape drive was powered off, the HSZ40 rebooted, and the
system then panicked with "simple_lock: time limit exceeded".
- When the system was under heavy load, the following group of three
errors was logged into the error logger every few minutes:
spo_verify_adap_sanity
spo_misc_errors
spo_bus_reset
- The system panicked with a kernel memory fault while trying to
remove an spo resource queue entry
- The system panicked with: "xpt_callback: callback on freed CCB"
PROBLEM: (Case ID: HPXQB83C7) (Patch ID: OSF350-099)
********
This patch fixes a panic caused by a "simple lock: time limit exceeded". A
sample stack trace for the problem CPU is as follows:
.......
.......
6 simple_lock_time_violation(slp = 0xfffffc00004fe1d0, state =
7 spo_go(spo_softc = 0xfffffc0039aae000, car_ptr =
8 spo_process_resource_q(spo_softc = 0xfffffc0039aae000)
9 spo_pool_alloc_thread()
OR
.......
.......
7 spo_immediate()
8 spo_process_resource_q(spo_softc = 0xfffffc0039aae000)
9 spo_pool_alloc_thread()
This stack trace may or may not come from the panicing cpu, depending on if
another cpu has been waiting longer on the spo resource queue lock. The panicing
cpu may have a stack trace showing a wait in the cam/spo subsystem, but one of
the cpus will show the stack trace listed above.
PROBLEM: (QAR 44545) (Patch ID: OSF350-164)
********
When running tape tests on a KZTSA SCSI adapter a data corruption problem
was found. This data corruption is only seen on large (> 1Meg) odd byte
transfers. It can occur on any tape drive connected to the KZTSA SCSI
adapter.
PROBLEM: (QAR 49540) (Patch ID: OSF350-353)
********
Infrequently, under heavy disk I/O loads, user data can be written to
the wrong disk, resulting in data corruption.
PROBLEM: (CLD HPXL85F5D) (Patch ID: OSF350-353)
********
In order to disconnect a tape drive from the bus for maintenance, Field Service
first quiesced the bus on the HSZ40, then powered off the tape drive.
When the tape drive was powered off, the HSZ40 rebooted, and the system
then panicked with "simple_lock: time limit exceeded".
The stack trace looked like this:
One CPU timed out waiting for the spo resource queue lock:
9 panic("simple_lock: time limit exceeded") [src/kernel/bsd/subr_prf.c:757]
10 simple_lock_fault() [src/kernel/kern/lock.c:1794]
11 simple_lock_time_violation(()) [src/kernel/kern/lock.c:1863]
12 spo_add_to_resource_q() [src/kernel/io/cam/spo/simport.c:1063]
13 spo_action() [src/kernel/io/cam/spo/simport.c:624]
while another CPU continued to hold the lock:
1 panic("cpu_ip_intr: panic request") [src/kernel/bsd/subr_prf.c:727]
2 cpu_ip_intr() [src/kernel/arch/alpha/cpu.c:487]
3 _XentInt() [src/kernel/arch/alpha/locore.s:961]
4 spo_immediate() [src/kernel/io/cam/spo/simport.c:2156]
5 spo_action_immediate() [src/kernel/io/cam/spo/simport.c:1026]
6 spo_action() [src/kernel/io/cam/spo/simport.c:579]
PROBLEM: (CLD HPXLB76FB) (Patch ID: OSF350-353)
********
When the system was under heavy load, the following group of 3 errors
was logged into the error logger every few minutes:
spo_verify_adap_sanity
spo_misc_errors
spo_bus_reset
The entire system would pause for up to 30 seconds, and then resume
normal operation right before each group of 3 errors above were logged.
PROBLEM: (QAR 45938, CLD HPAQ11CAJ) (Patch ID: OSF350-353)
********
The system panicked with a kernel memory fault while trying to remove
an spo resource queue entry:
10 panic("kernel memory fault")
11 trap()
12 _XentMM
13 spo_remove_queue_entry
14 spo_process_rsp
PROBLEM: (QAR 47247) (Patch ID: OSF350-353)
********
The system panicked with: "xpt_callback: callback on freed CCB"
6 panic("xpt_callback: callback on freed CCB")
7 xpt_callback() [src/kernel/io/cam/xpt.c:2420]
8 spo_process_ccb() [src/kernel/io/cam/spo/simport.c:3548]
9 spo_process_rsp() [src/kernel/io/cam/spo/simport.c:3467]
FILE(s):
/usr/sys/BINARY/simport.o subset OSFHWBIN350
CHECKSUM: 60285 176 RCSfile: simport.c RCS: 1.1.42.5
===============================================================================
SUPERSEDES PATCHES: OSF350-064 (64.00)
This patch corrects the following:
- Prevents a long delay while trying to log out using telnet.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0367U,USG-01718) (Patch ID: OSF350-064)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (QAR 41739 SPR UTO100828) (Patch ID: OSF350-373)
********
This patch prevents a long delay while trying to log out using telnet.
When logging in with telnet on a alpha 2100 5/250 (2 CPU), home directory
is advfs and using ksh and C2 security, it takes about 1 minute to logout.
FILE(s):
/usr/sbin/telnetd subset OSFCLINET350
CHECKSUM: 00921 80 RCSfile: telnetd.c RCS: 4.2.12.2
===============================================================================
SUPERSEDES PATCHES: OSF350-199 (199.00), OSF350-315 (353.00),
OSF350-368 (387.00)
This patch corrects the following:
- Fixes a problem for TLI applications which make use of the t_accept library
routine. The secondary endpoint state is not being set correctly.
- Corrects a problem encountered by tli applications which do
an abort disconnect on an endpoint which was established as an orderly
release endpoint and leave the endpoint in an unexpected state.
- This patch applies to the tli and xti library routines t_rcvrel and t_sndrel.
The t_rcvrel routine does not work properly in the T_DATAXFER state; it
returns T_OUTSTATE. The t_sndrel routine incorrectly returns a T_LOOK error.
- The problem of t_rcv NOT setting the error flag (t_errno) when no data is
retrieved.
PROBLEM: (TKTQ21539) (Patch ID: OSF350-199)
********
This patch applies to the tli and xti library routines t_rcvrel and t_sndrel.
The t_rcvrel routine does not work properly in the T_DATAXFER state; it returns
T_OUTSTATE. The t_sndrel routine incorrectly returns a T_LOOK error.
PROBLEM: (TKTQ80149) (Patch ID: OSF350-315)
********
This patch insures that t_errno is set even when trcv retrieves no data.
PROBLEM: (TKTQ30702) (Patch ID: OSF350-368)
********
This patch corrects a problem encountered by tli applications
which do an abort disconnect on an endpoint which was established
as an orderly release endpoint. Previously, such an event would leave
the endpoint in an unexpected state.
PROBLEM: (TKTQ52004) (Patch ID: OSF350-374)
********
This patch fixes a problem for TLI applications which make use of
the t_accept library routine.
The state of the secondary endpoint is not set correctly.
FILE(s):
/usr/ccs/lib/libtli.a subset OSFPGMR350
CHECKSUM: 42949 77
/usr/ccs/lib/libxti.a subset OSFPGMR350
CHECKSUM: 03397 80
/usr/shlib/libtli.so subset OSFBASE350
CHECKSUM: 45755 72
/usr/shlib/libxti.so subset OSFBASE350
CHECKSUM: 30787 56
/usr/sys/BINARY/xtiso.o subset OSFBIN350
CHECKSUM: 13712 119 RCSfile: xtiso.c RCS: 4.4.50.5
===============================================================================
SUPERSEDES PATCHES: OSF350-006 (6.00)
This patch corrects the following:
- Fixes a problem in which the system crashes when attempting
to NFS mount a text file.
- cat'ing files located on an NFS volume can cause an infinite copy.
PROBLEM: (EVT101253) (Patch ID: OSF350-006)
********
The cat command can cause an infinite copy if the following command is used
with the files located on an NFS volume:
cat file1 file2 file3 >file2
The output file2 may be any one of the input files _EXCEPT_ the first file
in the list. This will result in the cat command doing a continuous copy
until the output disk is full or quota is exhausted.
PROBLEM: (QAR 46893) (Patch ID: OSF350-375)
********
This patch fixes a problem in which the system crashes when
attempting to NFS mount a text file.
The panic backtrace will look similar to the following:
(kdbx) t
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c"]
1 panic("ubc_invalidate: NULL object")
["../../../../src/kernel/bsd/subr_prf.c"]
2 ubc_invalidate() ["../../../../src/kernel/vfs/vfs_ubc.c"]
3 nfs3_getattr_otw() ["../../../../src/kernel/nfs/nfs_client.c"]
4 nfs3getattr() ["../../../../src/kernel/nfs/nfs_client.c"]
5 nfs3_getattr() ["../../../../src/kernel/nfs/nfs3_vnodeops.c"]
6 vn_stat() ["../../../../src/kernel/vfs/vfs_vnops.c"]
7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c"]
8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c"]
9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c"]
10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s"]
(kdbx)
FILE(s):
/usr/sys/BINARY/nfs_client.o subset OSFBIN350
CHECKSUM: 10504 12 RCSfile: nfs_client.c RCS: 1.1.29.3
===============================================================================
Fixes a problem in which the tparm routine in the libcurses.a library
does not support more than a three digit value for its input parameter.
PROBLEM: (UTO100950) (Patch ID: OSF350-378)
********
This patch fixes a problem in which the tparm routine in the
libcurses.a library produces the wrong output value if the input parameter
has a value of more than three digits (greater than 999).
This patch fixes this problem and accepts a tparm parameter value of up to
four digits.
The following program can be run to reproduce the problem:
cat>>tparm_test.c<
#include
#include
main()
{
int lval;
char *str;
printf("enter value: ");
scanf("%d", &lval);
printf("enter value:%d\n ", lval);
str = (char *)calloc(16, sizeof(char));
strcpy(str, "\\E\[\%p1\%dX");
printf("string for substitution: %s\n", str);
str = (char *)tparm(str, lval);
printf("string after substitution : %s\n", str);
}
EOF
#cc -o tparm_test tparm_test.c -lcurses
#./tparm_test
enter value: 123
string for substitution: \E[%p1%dX
string after substitution : \E[123X (%p1 replaced by 123)
#
# ./tparm_test
enter value: 1234
string for substitution: \E[%p1%dX
string after substitution : \E[<34X (%p1 replaced by 34)
#
The correct string after substitution should be: \E[1234X
FILE(s):
/usr/ccs/lib/libcurses.a set OSFPGMR350
CHECKSUM: 22200 363
/usr/shlib/libcurses.so subset OSFBASE350
CHECKSUM: 44530 280
===============================================================================
Data written to a file greater than 32 GB in length will be slower than
data written to the file when it is less than 32 GB in length.
PROBLEM: (EVT101664) (Patch ID: OSF350-345)
********
This patch fixes a performance problem that occurs with UFS file systems.
Data written to a file greater than 32 GB in length will be slower than
data written to the file when it is less than 32 GB in length.
FILE(s):
/usr/sys/BINARY/ufs_bmap.o subset OSFBIN350
CHECKSUM: 15135 15 RCSfile: ufs_bmap.c RCS: 4.3.34.2
===============================================================================
This patch corrects the following:
- NFS mounted file systems may hang.
- The rpc.lockd program may fail because it loses a message granting
NLM approval.
- An NFS mounted file system may hang.
- The rpc.lockd daemon may crash with a core dump.
- An error occurs with NFS mounted user mail files. This error prevents
the files from being locked and prints out the following message:
cannot lockf
- An NFS problem may occur and the system displays the following error message:
NFS error 48 cannot bind sockets
PROBLEM: (QAR 51227,43271) (Patch ID: OSF350-352)
********
This patch fixes a problem that can cause an NFS mounted file system to hang.
The problem is caused by an incorrect FCNTL return.
PROBLEM: (QAR 14680) (Patch ID: OSF350-352)
********
This patch fixes a problem that can cause the rpc.lockd program to fail
because it loses a message granting NLM approval.
The message would be:
call unlock_res stat granted
rather than:
call lock_res stat blocked
PROBLEM: (QAR 45844) (Patch ID: OSF350-352)
********
This patch fixes a problem that can cause an NFS mounted file system to hang
during file locking.
PROBLEM: (QAR 46298) (Patch ID: OSF350-352)
********
This patch fixes a problem that can cause rpc.lockd to crash with a core dump.
Multi-vendor environments are particularly susceptible to this problem.
PROBLEM: (QAR 46630) (Patch ID: OSF350-352)
********
This patch fixes a problem that occurs with NFS mounted user mail files.
The error prevents the files from being locked and prints out
the following message:
cannot lockf
PROBLEM: (QAR 49265) (Patch ID: OSF350-352)
********
This patch fixes an NFS problem. The system displays the following
error message:
NFS error 48 cannot bind sockets
Other fixes include the cleanup of some error messages and to
direct more errors to syslog.
Additionally, the signal handler (SIGALRM) was redesigned to improve
the efficiency of retranmission and to prevent possible lost transmits.
FILE(s):
/usr/sbin/rpc.lockd subset OSFNFS350
CHECKSUM: 22596 136
===============================================================================
SUPERSEDES PATCHES: OSF350-020 (20.00), OSF350-119 (119.00)
OSF350-220 (220.00), OSF350-314 (352.00)
This patch corrects the following:
- Fix greatly reduces the number of "NFS stale file handle" messages
logged to an NFS server system console.
- Allows ome third-party NFS v2 clients to experience a performance improvement.
Candidate applications are ones that perform read/write operations
to a memory mapped file over NFS.
- System hang or panic with "kernel memory fault" if an NFS server is given
corrupted data.
- NFS clients, specifically SUN NFS clients, can not write files based on group
membership. OSF clients do not have this problem.
- Fixes a problem in which nfsportmon does not allow the root directory to be
mounted from either a Solaris system or from an ULTRIX Version 4.2A system.
PROBLEM: (Patch ID: OSF350-020) (HPAQ72013)
********
System hang or system panic with "kernel memory fault" if an nfs server
is given corrupted data.
The following is a sample stack trace from the panic:
xdr_name
xdr_diropargs
svckudp_getargs
rfs_dispatch
nfs_rpc_input
nfs_input
nfs_thread
PROBLEM: (CLD UTO100843) (Patch ID: OSF350-119)
********
NFS clients, specifically SUN NFS clients can't write files based on group
membership. OSF clients don't have this problem.
Given the following conditions:
- A directory contained in an NFS file system with a protection code of 755.
- A file contained in the directory with a protection code of 664.
- The directory and the file have the same group ownership.
With this patch, users or programs with the same group code
will have permission to modify the contents of the file.
PROBLEM: (HPAQC854C, QAR 46335) (Patch ID: OSF350-220)
********
This patch fixes a problem in which the nfsportmon command does not allow
the root directory to be mounted from either a Solaris system or from
an ULTRIX Version 4.2A system.
There is a program making it's way around the internet that allows
non-priviledged users to mount filesystems, even if the NFS server
is configured to only allow root users to mount (NONROOTMOUNTS=0
in /etc/rc.config). In order to protect against this, customers are
using nfsportmon to enhance the check mechanism. nfsportmon checks
to make sure that file access requests were generated by the client kernel
rather than a forged application.
However, with nfsportmon turned on, Sun Solaris clients cannot mount anything,
even as root.
For example, if you have a Digital UNIX v3.2c nfs server, and
NONROOTMOUNTS=0 and nfsportmon is on, the root user on another Digital UNIX
system can mount exported directories fine, but the root user on a Solaris
system cannot. The root user on a Solaris system gets the following error:
# mount sandpiper:/mnt /staff/ajs/mnt
nfs mount: sandpiper: NFS service not responding
nfs mount: retrying: /staff/ajs/mnt
With nfsportmon turned off, the directory mounts fine from Solaris.
In addition to Solaris clients failing, ULTRIX v4.2a clients also fail with
the same error.
PROBLEM: (CLD HPXQ9722E) (Patch ID: OSF350-314)
********
This patch allows some third-party NFS v2 clients to experience
a performance improvement. Candidate applications are ones that
perform read/write operations to a memory mapped file over NFS.
NOTES:
1) This patch must be enabled _BEFORE_ NFS is started because it needs
to perform some configuration operations before client requests start arriving.
This why the dbx patch is to the /vmunix file and not to memory.
If the patch is applied to memory, it will be ignored, since
the initialization routine only runs when NFS is started.
2) Affects NFS V2 only. NFS v3 connections are unaffected.
3) Files that are only read or only written will not be affected.
4) The NFS Dup cache and NFS Write Gathering are disabled by this patch.
To enable the patch, perform the following steps:
% dbx -k /vmunix
(dbx) patch stall_write_patch_enabled=1
(dbx) quit
% reboot
PROBLEM: (CLD FNO100139) (Patch ID: OSF350-382)
********
When a directory path on an NFS server is deleted, any process attempting
to access the missing path will cause NFS stale file handle messages
to be printed on the server's console.
This patch will greatly reduce the number of these messages.
FILE(s):
/usr/sys/BINARY/nfs_server.o subset OSFBIN350
CHECKSUM: 45996 178 RCSfile: nfs_server.c RCS: 1.1.90.9
/usr/sys/BINARY/nfs3_server.o subset OSFBIN350
CHECKSUM: 13963 169 RCSfile: nfs3_server.c RCS: 1.1.27.4
/usr/sys/BINARY/nfs_xdr.o subset OSFBIN350
CHECKSUM: 35169 16 RCSfile: nfs_xdr.c RCS: 1.1.31.2
/usr/sys/BINARY/vfs_syscalls.o subset OSFBIN350
CHECKSUM: 38065 45 RCSfile: vfs_syscalls.c RCS: 4.3.197.2
===============================================================================
SUPERSEDES PATCHES: OSF350-188 (188.00)
This patch corrects the following:
- Fixes a problem where the syslogd program cannot properly forward
large messages to remote systems. It will either write them to
the wrong facility (specified in /etc/syslog.conf) or write incomplete data.
- After a login session on /dev/console exits, syslogd cannot write to
/dev/console.
PROBLEM: (MGO101831) (Patch ID: OSF350-188)
********
After a login session on /dev/console exits, syslogd cannot write to
/dev/console
PROBLEM: (TKTB51380) (Patch ID: OSF350-383)
********
This patch fixes a problem in which the syslogd program
cannot properly forward large messages to remote systems.
It will either write them to the wrong facility
(specified in /etc/syslog.conf) or write incomplete data.
FILE(s):
/usr/sbin/syslogd subset OSFBASE350
CHECKSUM: 41410 40 RCSfile: syslogd.c RCS: 4.2.25.3
===============================================================================
SUPERSEDES PATCHES: OSF350-041 (41.00), OSF350-084 (84.00),
OSF350-151 (151.00), OSF350-158 (158.00),
OSF350-146 (146.00), OSF350-192 (192.00),
OSF350-193 (193.00), OSF350-195 (195.00),
OSF350-248 (248.00), OSF350-294 (294.00),
OSF350-305 (343.00), OSF350-319 (357.00),
OSF350-338 (374.00), OSF350-342 (392.00),
OSF350-365 (384.00), OSF350-381 (408.00)
This patch corrects the following:
- Enhanced fix to the solockpair() routine; problem symptoms include
kernel memory faults with sockets, mbufs and mblocks as well as hangs.
Applications using sockets in a multi-threaded, multi-cpu environment can
experience a number of lock violations with the socket structures.
- Fixes a problem in which packet filter programs do not receive packets
when the source is sending multicast packets on an Ethernet network.
- Fixes a problem in which network applications communicating to
one of the host's own addresses, may hang, or receive the error message:
no buffer space available
- System crashes with "Unaligned kernel space access from kernel mode"
(Packetfilter unaligned access panic from ipintr).
- When writing packets using the packetfilter on FDDI, there are 14 bytes
of corruption in the link layer header of the packet, so the packet appears
corrupted on the FDDI ring.
- A "panic: lock_read: hierarchy violation in del_dealloc_stg" error occurs
when a socket lock is held by a UNIX domain while calling vrele().
- An SMP machine running a large number of web server daemons, for example,
"ns-httpd" or "httpd", may experience an SMP race condition that will cause
the system to panic.
- Improves the performance of the network on a system being used as a web
server. There are additional tuneable parameters included to be used by the
highly informed system admin.
- A user on a remote host can cause a Digital UNIX host to hang or panic.
- Fixes a problem in which the system panics when an interface is deleted.
- Provides a new tcp level socket option called TCP_NODELACK. This socket
option allows a user to force an ack (acknowledge) after each received
packet.
- Fixes a problem in which broadcast packets are received by a daemon listening
to a port that is using both the INP_RECVDSTADDR and SO_REUSEPORT socket
options. The packets were not being delivered to the listening daemon.
- Fixes a kernel memory fault panic that occurs on SMP platforms. The problem
occurs when running the Unicenter product from Computer Associates in
conjunction with Oracle software.
- Fixes a system panic caused by a Windows95 or WindowsNT system sending an
illegal length ping ( ICMP ) packet.
- A kernel fix for network sockets left in FIN_WAIT_1 state forever. This
patch contains a "tunable" kernel parameter. It is recommended that only
experienced system administrators attempt to set this parameter from the
default value.
- Fixes ICMP REDIRECTS. When an ICMP REDIRECT is received, the routing table
was updated properly, but the IP layer didn't use the new route information.
- Fixes a problem where a system attempts to ping a Digital UNIX system
connected to a token ring network and the ping uses a message size that
requires fragmentation. The Digital UNIX system receiving the ping cannot
respond. The token ring driver displays the following error message
to the console and resets the token ring adapter:
List Error in transmit
PROBLEM: (CLD HPAQ738E0) (Patch ID: OSF350-041, OSF350-084)
********
System crashes with "Unaligned kernel space access from kernel mode".
The system uses the packetfilter option and "copyall" mode to receive
loopback packets sent via the packetfilter. The crash shows an unaligned
access (longword access attempt using a non-longword address) from ipintr.
The problem occurs whenever a packet larger than 170 bytes is written through
the packetfilter and the packet is a loopback packet (destined for the local
machine) or a broadcast packet (which gets copied to the local host).
Software packages which can trigger this include: Insignia "SoftWindows"
and LISP "OpenGenera" software from Symbolics, Inc. Both of these packages
use the packetfilter subsystem with the loopback feature and the "copyall"
packetfilter flag.
The kernel stack trace looks like:
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620]
1 panic("Unaligned kernel space access from kernel mode")
["../../../../src/kernel/bsd/subr_prf.c":752]
2 afault_print() ["../../../../src/kernel/arch/alpha/trap.c":1486]
3 _XentUna() ["../../../../src/kernel/arch/alpha/locore.s":1429]
4 ipintr() ["../../../../src/kernel/netinet/ip_input.c":526]
5 netisr_thread() ["../../../../src/kernel/net/netisr.c":825]
PROBLEM: (CLD 7AZB92029) (Patch ID: OSF350-041, OSF350-084)
********
When writing packets using the packetfilter on FDDI, there are 14 bytes of
corruption in the link layer header of the packet, so the packet appears
corrupted on the FDDI ring. This fix is to the FDDI/packet filter code for an
erroneous write-side bcopy, which has been corrected.
This problem does not occur using Ethernet. It is included here so that
patch #1 does not get overwritten. There is no impact (side effects, etc.) if
this patch is installed when FDDI is not being used.
PROBLEM: (MCPMC5074, MCPM12C58, MCPM18F82) (Patch ID: OSF350-151)
********
An SMP machine running a large number of web server daemons, for example,
"ns-httpd" or "httpd", may experience an SMP race condition that will cause the
system to panic. These panics occur when the web server daemons all accept
incoming sockets on the same head socket.
The following are examples of potential stack traces that illustrate the
problem addressed by this CLD:
Example of "Unaligned kernel space access from kernel mode" panic:
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669 ]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
5 panic("Unaligned kernel space access from kernel mode")
["../../../../src/kernel/bsd/subr_prf.c":719 ]
6 afault_print() ["../../../../src/kernel/arch/alpha/trap.c":1418 ]
7 _XentUna() ["../../../../src/kernel/arch/alpha/locore.s":1443 ]
8 sounlock_ext() ["../../../../src/kernel/bsd/uipc_socket.c":634 ]
9 sodequeue() ["../../../../src/kernel/bsd/uipc_socket.c":1925 ]
10 accept1() ["../../../../src/kernel/bsd/uipc_syscalls.c":393 ]
11 oaccept() ["../../../../src/kernel/bsd/uipc_syscalls.c":319 ]
12 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519 ]
13 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094 ]
Example of "kernel memory fault" panic:
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669 ]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":719 ]
6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213 ]
7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307 ]
8 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":662 ]
9 sonewsock() ["../../../../src/kernel/bsd/uipc_socket2.c":380 ]
10 tcp_input() ["../../../../src/kernel/netinet/tcp_input.c":611 ]
11 ipintr() ["../../../../src/kernel/netinet/ip_input.c":715 ]
12 netisr_thread() ["../../../../src/kernel/net/netisr.c":806 ]
Example of "simple_lock: minimum spl violation" panic (when lockmode = 4):
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669 ]
12 netisr_thread() ["../../../../src/kernel/net/netisr.c":806 ]
Example of "simple_lock: minimum spl violation" panic (when lockmode = 4):
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":368 ]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669 ]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":725 ]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810 ]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355 ]
5 panic("simple_lock: minimum spl violation")
["../../../../src/kernel/bsd/subr_prf.c":719 ]
6 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":1794 ]
7 simple_lock_minspl_violation() ["../../../../src/kernel/kern/lock.c":1841 ]
8 lock_write() ["../../../../src/kernel/kern/lock.c":473 ]
9 solock_ext() ["../../../../src/kernel/bsd/uipc_socket.c":616 ]
10 sodequeue() ["../../../../src/kernel/bsd/uipc_socket.c":1922 ]
11 accept1() ["../../../../src/kernel/bsd/uipc_syscalls.c":393 ]
12 oaccept() ["../../../../src/kernel/bsd/uipc_syscalls.c":319 ]
13 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":534 ]
14 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094 ]
PROBLEM: (QAR 45094) (Patch ID: OSF350-158)
********
This patch improves the performance of the network on a system being used as a
web server. There are additional tuneable parameters included to be used by the
very knowledgeable system administrators.
CAUTION: Only experienced network system administrators should
be using these parameters to modify their system. Adverse effects
may result. In-depth knowledge of the network and it’s workings
is required.
PLEASE DO give this to major customers running big systems as web
servers. They will have the people who understand the features being
provided.
TUNING
To tune the web server, the number of simultaneous socket connection requests
are limited by:
somaxconn Sets the maximum number of pending requests
allowed to wait on a listening socket. The
default value in Digital UNIX V3.2 is 8.
This patch kit increases the default to 1024,
which matches the value in Digital UNIX V4.0.
sominconn Sets the minimum number of pending connections
allowed on a listening socket. When a user
process calls listen with a backlog less
than sominconn, the backlog will be set to
sominconn. sominconn overrides somaxconn.
The default value is 1.
The effectiveness of tuning these parameters can be monitored by
the sobacklog variables available in the kernel:
sobacklog_hiwat Tracks the maximum pending requests to any
socket. The initial value is 0.
sobacklog_drops Tracks the number of drops exceeding the
socket set backlog limit. The initial
value is 0.
somaxconn_drops Tracks the number of drops exceeding the
somaxconn limit. When sominconn is larger
than somaxconn, tracks the number of drops
exceeding sominconn. The initial value is 0.
TCP timer parameters also effect performance. Tuning the following
require some knowledge of the characteristics of the network.
tcp_msl Sets the tcp maximum segment lifetime.
This is the maximum lifetime in half
seconds that a packet can be in transit
on the network. This value, when doubled,
is the length of time a connection remains
in the TIME_WAIT state after a incoming
close request is processed. The unit is
specified in 1/2 seconds, the initial
value is 60.
tcp_rexmit_interval_min
Sets the minimum TCP retransmit interval.
For some WAN networks the default value may
be too short, causing unnecessary duplicate
packets to be sent. The unit is specified
in 1/2 seconds, the initial value is 1.
tcp_keepinit This is the amount of time a partially
established connection will sit on the listen
queue before timing out (e.g. if a client
sends a SYN but never answers our SYN/ACK).
Partially established connections tie up slots
on the listen queue. If the queue starts to
fill with connections in SYN_RCVD state,
tcp_keepinit can be decreased to make those
partial connects time out sooner. This should
be used with caution, since there might be
legitimate clients that are taking a while
to respond to SYN/ACK. The unit is specified
in 1/2 seconds, the default value is 150
(ie. 75 seconds).
The hashlist size for the TCP inpcb lookup table is regulated by:
tcbhashsize The number of hash buckets used for the
TCP connection table used in the kernel.
The initial value is 32. For best results,
should be specified as a power of 2.
The hashlist size for the interface alias table is regulated by:
inifaddr_hsize The number of hash buckets used for the
interface alias table used in the kernel.
The initial value is 32. For best results,
should be specified as a power of 2.
The maximum system assigned user port number is limited by:
ipport_userreserved The largest port number given to a user
process requesting a system-assigned port
(INADDR_ANY). The default is 5000, which
allows 3975 ports to be assigned in the
range 1025-5000. The maximum is value
is 65535.
PROBLEM: (FNO100098) (Patch ID: OSF350-146)
********
A user on a remote host can cause a Digital UNIX host to hang or panic. A
typical stack trace follows.
1 panic("thread_block: interrupt level call")
["../../../../src/kernel/bsd/subr_prf.c":673]
2 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1744]
3 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3456]
4 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1671]
5 panic("Processor Machine Check") ["../../../../src/kernel/bsd/subr_prf.c":757]
6 kn470_machcheck() ["../../../../src/kernel/arch/alpha/hal/kn470.c":833]
7 mach_error() ["../../../../src/kernel/arch/alpha/hal/cpusw.c":801]
8 _XentInt() ["../../../../src/kernel/arch/alpha/locore.s":997]
9 in_checksum() ["../../../../src/kernel/arch/alpha/in_checksum.s":103]
10 in_cksum() ["../../../../src/kernel/arch/alpha/in_cksum.c":112]
11 icmp_input() ["../../../../src/kernel/netinet/ip_icmp.c":335]
12 ipintr() ["../../../../src/kernel/netinet/ip_input.c":715]
13 netisr_thread() ["../../../../src/kernel/net/netisr.c":806]
PROBLEM: (QAR 37825) (Patch ID: OSF350-192)
********
This patch fixes a problem in which the system panics when an interface
is deleted. The following is an example of a typical stack trace:
1 panic( "in_delmulti" )
2 in_delmulti() netinet/in.c"1409
3 ip_freemoptions() netinet/ip_output.c":1423
4 in_pcbfree() netinet/in_pcb.c":590
5 in_pcbdetach() netinet/in_pcb.c":561
6 udp_usrreq() netinet/udp_usrreq.c":1039
7 soclose() bsd/uipc_socket.c":799
8 soo_close() bsd/sys_socket.c":401
9 closef() bsd/kern_descrip.c":1468
10 close() bsd/kern_descrip.c":1146
11 syscall()
PROBLEM: (QAR 38134) (Patch ID: OSF350-193)
********
This patch provides a new tcp level socket option called TCP_NODELACK. This
socket option allows a user to force an ack (acknowledge) after each received
packet.
PROBLEM: (Patch ID: OSF350-195)
********
This patch fixes a problem in which broadcast packets are received by
a daemon listening to a port that is using both the INP_RECVDSTADDR
and SO_REUSEPORT socket options. The packets were not being
delivered to the listening daemon.
PROBLEM: (USG-03327) (Patch ID: OSF350-248)
********
This patch fixes a kernel memory fault panic that occurs on SMP platforms.
The problem occurs when running the Unicenter product from Computer Associates
in conjunction with Oracle software.
This panic will show a variety of stack traces due to memory corruption
caused by the inadvertant freeing of a memory block. The panic string will
always be "kernel memory fault".
1 panic(s = "kernel memory fault") subr_prf.c:757
2 trap() trap.c:1223
3 _XentMM() locore.s:1307
4 obj_entry_find() ipc_prims.c:112
5 port_dealloc() ipc_kport.c:331
6 ipc_task_terminate() ipc_tt.c:373
7 task_terminate() task.c:648
8 exit() kern_exit.c:922
9 rexit() kern_exit.c:635
10 Enf_exit() enfk_exit.c:121
11 syscall() syscall_trap.c:519
9 panic(s = "kernel memory fault") subr_prf.c:757
10 trap() trap.c:1223
11 _XentMM()locore.s:1307
12 malloc() kern_malloc.c:747
13 msg_copyin() ipc_copyin.c:414
14 msg_rpc_trap() ipc_basics.c:1405
15 _Xsyscall() locore.s:1249
7 panic(s = "kernel memory fault") subr_prf.c:757
8 trap() trap.c:1223
9 _XentMM()locore.s:1307
10 ubc_flush_dirty() vfs_ubc.c:2978
11 ufs_fsync_int() ufs_vnops.c:2007
12 ufs_fsync() ufs_vnops.c:2105
13 ufs_sync() ufs_vfsops.c:1600
14 sync() vfs_syscalls.c:1395
15 syscall() syscall_trap.c:519
PROBLEM: (FNO100128) (Patch ID: OSF350-294)
********
This patch fixes a system panic caused by a Windows95 or WindowsNT system
sending an illegal length ping ( ICMP ) packet. This patch is MANDATORY.
PROBLEM: (QAR 49023) (Patch ID: OSF350-305)
********
A "panic: lock_read: hierarchy violation in del_dealloc_stg" error occurs
when a socket lock is held by a UNIX domain while calling vrele().
PROBLEM: (MCPMA986D) (Patch ID: OSF350-319)
********
This patch is a kernel fix for network sockets left in FIN_WAIT_1 state forever.
This patch contains a "tunable" kernel parameter. It is recommended that
only experienced system administrators attempt to set this parameter from
the default value.
How to recognize this problem.
This is an example of the problem with tcpdump running in the background
listening on the destination ip address shown in the netstat output.
# netstat -An | grep 203.232.10.221
Active Internet connections
PCB Proto Recv-Q Send-Q Local Address Foreign Address (state)
94276c00 tcp 0 759 192.86.154.82.80 203.232.10.221.162
FIN_WAIT_1
9418ef00 tcp 0 759 192.86.154.82.80 203.232.10.221.162
FIN_WAIT_1
13:28:03.472384 www-2.us.oracle.com.80 > 203.232.10.221.1626: . 0:1(1) ack 1
win 33232
13:28:12.973072 www-2.us.oracle.com.80 > 203.232.10.221.1623: . 0:1(1) ack 1
win 33232
What is observed here is the destination is clearly dead. The source is
sending an ACK to the destination looking for his ACK of our FIN.
This is commonly refered to as "persist mode". A socket in this state will
never timeout and system resources associated with it will not be
released.
The new kernel modification to tcp_timer.o can be "tuned" by dbx'ing the
tcp_keepidle parameter on the system. By default, this is set to 14400
1/2 seconds (2 hours). It can be easily set to any value appropriate for
the system to "balance" the number of sockets in FIN_WAIT_1 state at any
time. The system may always have some sockets in FIN_WAIT_1 as well as
CLOSE_WAIT, this is NORMAL. What you don't want is a large number of sockets
in FIN_WAIT_1 forever. It is not recommended that tcp_keepidle be set to
less than 5 minutes on the system.
Reference the man page to dbx for guidelines when using the dbx command.
PROBLEM: (ZUO101015/QAR 49750) (Patch ID: OSF350-338)
********
This patch fixes ICMP REDIRECTS. When an ICMP REDIRECT is received,
the routing table was updated properly, but the IP layer didn't use
the new route information.
PROBLEM: (CA7Q10994) (Patch ID: OSF350-342)
********
This patch fixes a problem that occurs on all systems that use
networking services.
The problem can be seen when a system attempts to ping a Digital UNIX system
connected to a token ring network and the ping uses a message size that
requires fragmentation. The Digital UNIX system receiving the ping cannot
respond. The token ring driver displays the following error message
to the console and resets the token ring adapter:
List Error in transmit
PROBLEM: (CLD MCPM3028N) (Patch ID: OSF350-365)
********
This patch fixes a problem in which network applications communicating to
one of the host's own addresses, may hang, or receive the error message:
no buffer space available
The problem occurs due to a queue full condition on the interface.
In an Available Server (ASE) or TruCluster environment, the daemons will
no longer be able to communicate with each other, and the asemgr utility
will appear to hang.
PROBLEM: (CLD UVO105250) (Patch ID: OSF350-381)
********
This patch fixes a problem in which packet filter programs do not receive
packets when the source is sending multicast packets on an Ethernet network.
PROBLEM: (MGO102810,QAR 49847) (Patch ID: OSF350-384)
********
This patch is an enhanced fix to the solockpair() routine.
This fix was needed because the routine was freeing a socket lock structure
that was concurrently spun upon in lock_write(). Typical problem symptoms
include kernel memory faults with sockets, mbufs and mblocks as well as hangs.
Applications using sockets in a multi-threaded, multi-cpu environment can
experience a number of lock violations with the socket structures.
This patch is MANDATORY to install on all systems. It will be effective
on Uniprocessor systems when lockmode debugging is invoked.
FILE(s):
/usr/sys/BINARY/if_ether.o subset OSFBIN350
CHECKSUM: 39658 89 RCSfile: if_ether.c RCS: 4.3.42.2
/usr/sys/BINARY/if_ethersubr.o subset OSFBIN350
CHECKSUM: 12905 17 RCSfile: if_ethersubr.c RCS: 4.4.59.5
/usr/sys/BINARY/ip_input.o subset OSFBIN350
CHECKSUM: 05482 23 RCSfile: ip_input.c RCS: 4.4.49.5
/usr/sys/BINARY/in.o subset OSFBIN350
CHECKSUM: 27728 20 RCSfile: in.c RCS: 4.3.38.3
/usr/sys/BINARY/ip_output.o subset OSFBIN350
CHECKSUM: 14010 17 RCSfile: ip_output.c RCS: 4.4.43.3
/usr/sys/BINARY/in_pcb.o subset OSFBIN350
CHECKSUM: 50510 15 RCSfile: in_pcb.c RCS: 4.3.47.3
/usr/sys/BINARY/lockprim.o subset OSFBIN350
CHECKSUM: 21282 15 RCSfile: lockprim.s RCS: 1.1.40.3
/usr/sys/BINARY/tcp_input.o subset OSFBIN350
CHECKSUM: 00804 22 RCSfile: tcp_input.c RCS: 4.3.54.3
/usr/sys/BINARY/tcp_subr.o subset OSFBIN350
CHECKSUM: 48209 11 RCSfile: tcp_subr.c RCS: 4.3.40.3
/usr/sys/BINARY/tcp_timer.o subset OSFBIN350
CHECKSUM: 26601 9 RCSfile: tcp_timer.c RCS: 4.2.15.3
/usr/sys/BINARY/tcp_usrreq.o subset OSFBIN350
CHECKSUM: 17927 10 RCSfile: tcp_usrreq.c RCS: 4.3.25.3
/usr/sys/BINARY/udp_usrreq.o subset OSFBIN350
CHECKSUM: 53035 89 RCSfile: udp_usrreq.c RCS: 4.3.44.4
/usr/sys/BINARY/uipc_socket.o subset OSFBIN350
CHECKSUM: 53236 26 RCSfile: uipc_socket.c RCS: 4.3.63.5
/usr/sys/BINARY/uipc_socket2.o subset OSFBIN350
CHECKSUM: 04162 15 RCSfile: uipc_socket2.c RCS: 4.4.37.2
/usr/sys/BINARY/uipc_usrreq.o subset OSFBIN350
CHECKSUM: 45645 17 RCSfile: uipc_usrreq.c RCS: 4.3.44.3
/usr/sys/include/net/proto_uipc.h subset OSFBINCOM350
CHECKSUM: 65313 10 RCSfile: proto_uipc.h RCS: 4.2.21.3
/usr/sys/include/sys/socket.h subset OSFBINCOM350
CHECKSUM: 58113 12 RCSfile: socket.h RCS: 4.2.24.3
/usr/sys/include/sys/socketvar.h subset OSFBINCOM350
CHECKSUM: 35066 15 RCSfile: socketvar.h RCS: 4.2.26.3
/usr/sys/io/common/conf.c subset OSFBINCOM350
CHECKSUM: 36475 47 RCS: 1.2.209.2
/usr/sys/io/common/.mrg..conf.c subset OSFBINCOM350
CHECKSUM: 60138 2
===============================================================================
SUPERSEDES PATCH: OSF350-172 (172.00), OSF350-183 (183.00)
This patch corrects the following:
- Fixes a problem where the lpq command causes the program to crash
(segmentation fault).
- Print jobs cause existing jobs to be deleted from the queue whenever the
number of print queue entries exceeded 1000.
- Print jobs created within a short timeframe, for example within the same
second, were not sorted by print jobs and timestamps.
PROBLEM: ( HPXQ846D7 ) (Patch ID: OSF350-172)
********
This patch corrects a problem where printjobs cause existing jobs to be deleted
from the queue whenever the number of print queue entries exceeded 1000.
Example:
The cfA005bozo file in /usr/spool/lpxx exists.
The next print queue tries to create cfA005bozo.
After error message "Cannot create cfA005bozo" shows up, do
"ls -l /usr/spoo/lpxx/cfA005bozo". This file will be
deleted.
PROBLEM: ( MGO101607 ) (Patch ID: OSF350-183)
********
This patch corrects a problem in which print jobs created within a short
timeframe, for example within the same second, were not sorted by print jobs
and timestamps. This resulted in print jobs not being printed in the desired
order.
Example: Prior to the fix
#ls -tr *.lis
users.lis users1.lis users2.ls users3.lis users4.lis
users5.lis
.
# foreach i (`ls -tr *.lis`)
? lpr -Pxxx $i
? end
.
# ls -lt /var/spool/xxx/cf*
-rw-rw---- 1 daemon daemon 132 Jul 11 10:07 cfA005osfmbh
.aui.dec.com
-rw-rw---- 1 daemon daemon 132 Jul 11 10:07 cfA007osfmbh
.aui.dec.com
-rw-rw---- 1 daemon daemon 132 Jul 11 10:07 cfA006osfmbh
.aui.dec.com
-rw-rw---- 1 daemon daemon 132 Jul 11 10:07 cfA004osfmbh
.aui.dec.com
-rw-rw---- 1 daemon daemon 132 Jul 11 10:07 cfA003osfmbh
.aui.dec.com
# lpq -Pxxx
Fri Feb 17 10:46:29 1995:
Rank Pri Owner Job Files Total Size
1st 0 bozo 3 users.lis 23
2nd 0 bozo 4 users1.lis 23
3rd 0 bozo 6 users3.lis 23
4th 0 bozo 7 users4.lis 23
5th 0 bozo 5 users2.lis 23
6th 0 bozo 8 users5.lis 23
As you can see, the file users2.lis has Job number 5 which is the 3rd Job
but gets ranked in the 5th position and will not be printed in the desired order
after the file user1.lis despite of the fact that all files had been created with the
same timestamp (eg. Jul 11 10:07).
Example: the order should be the following after the fix
# lpq -Pxxx
Fri Feb 17 10:46:29 1995:
Rank Pri Owner Job Files Total Size
1st 0 bozo 3 users.lis 23
2nd 0 bozo 4 users1.lis 23
3rd 0 bozo 5 users2.lis 23
4th 0 bozo 6 users3.lis 23
5th 0 bozo 7 users4.lis 23
6th 0 bozo 8 users5.lis 23
PROBLEM: (QAR 52528) (Patch ID: OSF350-392)
********
This patch fixes a problem where the lpq command causes the program to crash
(segmentation fault).
The problem is caused by lpq running until a print queue buffer
in memory is overwritten.
The following is an example of a core dump:
dove.zk3.dec.com: Thu May 19 18:11:54 1994:
ps29 is ready and printing via network
Rank Owner Job Files Total Size
active achan 27 ... 789505 bytes
1st achan 28 ... 790831 bytes
2nd achan 29 ... 696441 bytes
3rd achan 30 ... 509919 bytes
Unaligned access pid=2581 va=6f70732f7261762f pc=3ff80129608
ra=3ff80129194 type=ldq
Segmentation fault
FILE(s):
/usr/lbin/lpd subset OSFPRINT350
CHECKSUM: 40158 96 RCSfile: lpd.c RCS: 4.2.17.2
RCSfile: lpdchar.c RCS: 4.2
RCSfile: displayq.c RCS: 4.2.12.2
/usr/bin/lpr subset OSFPRINT350
CHECKSUM: 31966 48 RCSfile: lpr.c RCS: 4.2.33.2
/usr/bin/lprm subset OSFPRINT350
CHECKSUM: 00821 40 RCSfile: lprm.c RCS: 4.2.6.2
/usr/bin/lpq subset OSFPRINT350
CHECKSUM: 52934 48 RCSfile: lpq.c RCS: 4.2.5.2
RCSfile: displayq.c RCS: 4.2.12.2
===============================================================================
Fixes a problem in which the cron command deletes non-local file system files
mounted in either the /tmp, /var/tmp, or /var/preserve directories.
PROBLEM: (QAR 46084) (Patch ID: OSF350-390)
********
This patch fixes a problem in which the cron command removes
non-local file system files mounted in either
the /tmp, /var/tmp, or /var/preserve directories.
FILE(s):
/usr/var/spool/cron/crontabs/.new..root subset OSFBASE350
CHECKSUM: 51745 2 RCSfile: root RCS: 4.3.24.2
/usr/var/spool/cron/crontabs/.mrg..root subset OSFBASE350
CHECKSUM: 25699 5 RCSfile: .mrg..root RCS: 1.1.15.2
===============================================================================
- A potential security vulnerability has been discovered in bind, where
under certain circumstances users may gain unauthorized access.
Digital has corrected this potential vulnerability.
PROBLEM: (CLD-00805) (Patch ID: OSF350-348C)
********
A potential security vulnerability has been discovered in BIND
(Domain Name Service), where under certain circumstances,
system integrity may be compromised.
This may be in the form of improper file or privilege management.
Digital has corrected this potential vulnerability.
FILE(s):
/usr/bin/uucp subset OSFUUCP350
CHECKSUM: 09841 336 RCSfile: uucp.c RCS: 4.3.8.2
RCSfile: uucpdefs.c RCS: 4.3.6.3
RCSfile: uucpname.c RCS: 4.3.5.2
/usr/lib/uucp/uucico subset OSFUUCP350
CHECKSUM: 62761 480
/usr/lib/uucp/uucleanup subset OSFUUCP350
CHECKSUM: 61605 320 RCSfile: uucleanup.c RCS: 4.3.8.3
/usr/sbin/uucpd subset OSFUUCP350
CHECKSUM: 47563 272 RCSfile: uucpd.c RCS: 4.3.6.3
===============================================================================
SUPERSEDES PATCHES: OSF350-159 (159.00), OSF350-205 (205.00),
OSF350-389 (201.01), OSF350-391 (414.00)
This patch corrects the following:
- Fixes a problem in which the vrestore command is unable
to read data from a raw disk partition.
- Fixes a problem where the vrestore program does not report
failed exit status appropriately on incomplete or incorrect commands,
corrupt or invalid saved sets, or file open failures.
- Fixes a problem in which the vrestore command fails when running
multiple iterations of the command in a script or from the command line.
- Fix incorrect vdump file count message that shows up when vdump backs up
a filesystem containing sockets.
- User will receive the following error message if they attempt to restore a
V4.0 dump on an older version of the OS:
vrestore: Need vrestore V4.0 to restore contenets; terminating
PROBLEM: (QAR 44852) (Patch ID: OSF350-159)
********
User will receive the following error message if they attempt to restore a
V4.0 dump on an older version of the OS:
vrestore: Need vrestore V4.0 to restore contenets; terminating
PROBLEM: (QAR 28861) (Patch ID: OSF350-205)
********
After vdump completes, it may report that it backed up > 100% of the files.
vdump: Dumped 927 of 924 files; 100.3% completed
as root, try: # vdump -0 -f - /dev > /dev/null
PROBLEM: (QAR 53017) (Patch ID: OSF350-389)
********
This patch fixes a problem in which the vrestore command fails
when running multiple iterations of the command in a script
or from the command line.
To reproduce this problem, create a shell script similar to the
following called vrestore.sh:
vrestore tf vdump_file.1 &
vrestore tf vdump_file.2 &
vrestore tf vdump_file.3 &
Run the shell script. The system will display error messages
similar to the following:
vrestore: Date of the vdump save-set: Tue Apr 16 13:49:20 1996
vrestore: Date of the vdump save-set: Tue Apr 16 13:49:30 1996
vrestore: Date of the vdump save-set: Tue Apr 16 13:49:35 1996
logical_dir_creat() -- unimplemented
vrestore: can't create restore dir ; [17] File exists
vrestore: dir_write() error; [9] Bad file number; terminating
PROBLEM: (UVO105368) (Patch ID: OSF350-391)
********
This patch fixes a problem where the vrestore program does not report
failed exit status appropriately on incomplete or incorrect commands,
corrupt or invalid saved sets, or file open failures.
PROBLEM: (QAR 47535) (Patch ID: OSF350-395)
********
This patch fixes a problem in which the vrestore command is unable
to read data from a raw disk partition.
# vdump -0 -D -f /dev/rz5c -x32 /scratch
path : /scratch
dev/fset : /dev/rz1a
type : ufs
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 4101 bytes, 1 directories, 1 files
vdump: Dumping regular files
vdump: Status at Tue Jun 10 07:08:33 1997
vdump: Dumped 4101 of 4101 bytes; 100.0% completed
vdump: Dumped 1 of 1 directories; 100.0% completed
vdump: Dumped 1 of 1 files; 100.0% completed
vdump: Dump completed at Tue Jun 10 07:08:33 1997
# vrestore -x -f /dev/rz5c -D /recover junk
vrestore: raw disk
vrestore: Unsupported device category 1
FILE(s):
/sbin/vdump subset OSFADVFS350
CHECKSUM: 09889 632 RCSfile: vdump.c RCS: 1.1.26.2
/sbin/vrestore subset OSFADVFS350
CHECKSUM: 28202 640 RCSfile: vrestore.c RCS: 1.1.26.4
===============================================================================
SUPERSEDES PATCHES: OSF350-055 (55.00), OSF350-103 (103.00),
OSF350-106 (106.00), OSF350-110 (110.00),
OSF350-113 (113.00), OSF350-125 (125.00),
OSF350-126 (126.00), OSF350-136 (136.00),
OSF350-104 (104.00), OSF350-138 (138.00),
OSF350-118 (118.00), OSF350-134 (134.00),
OSF350-157 (157.00), OSF350-141 (141.00),
OSF350-170 (170.00), OSF350-173 (173.00),
OSF350-184 (184.00), OSF350-202 (202.00),
OSF350-203 (203.00), OSF350-179 (179.00),
OSF350-016 (16.00), OSF350-024 (24.00),
OSF350-060 (60.00), OSF350-079 (79.00),
OSF350-083 (83.00), OSF350-101 (101.00),
OSF350-036 (36.00), OSF350-142 (142.00),
OSF350-212 (212.00), OSF350-225 (225.00),
OSF350-235 (235.00), OSF350-235-1 (235.01),
OSF350-242 (242.00), OSF350-242-1 (242.01),
OSF350-264 (264.00), OSF350-265 (265.00),
OSF350-014 (14.01), OSF350-098 (98.00),
OSF350-166 (166.00), OSF350-227 (227.00),
OSF350-258 (258.00), OSF350-251 (251.00),
OSF350-082 (82.00), OSF350-135 (135.00),
OSF350-277 (277.00), OSF350-280 (280.00),
OSF350-284 (284.00), OSF350-290 (290.00),
OSF350-295 (295.00), OSF350-321 (359.00),
OSF350-360 (379.00), OSF350-360-1 (379.01),
OSF350-369 (388.00), OSF350-371 (390.00),
OSF350-372 (397.00), OSF350-376 (402.00)
OSF350-379 (406.00), OSF350-438 (349.00),
OSF350-438-1 (349.01),
OSF350-309 (347.00), OSF350-182 (182.00),
OSF350-366 (385.00), OSF350-403 (423.00),
OSF350-405 (425.00), OSF350-408 (427.00),
OSF350-427 (441.00), OSF350-430 (442.00),
OSF350-435 (445.00), OSF350-440 (447.00),
OSF350-442 (448.00), OSF350-448 (453.00),
OSF350-456 (457.00), OSF350-460 (437.00)
This patch corrects the following:
- Fixes a system crash when setting the date on SMP systems.
- Fixes a system panic with the following panic string:
"event_timeout: panic request"
- Fixes a SCSI error recovery problem to allow fast recovery from disk errors.
- Fixes a problem that occurs when starting up a system
that is running the auditing subsystem and the performance manager.
The system panics with the error message: kernel memory fault
- Provides general support for Version A11 KZPSA firmware.
- Fixes the problem of a system hang due to corruption of
a STREAM synchronization queue's forward pointer.
The system hangs in the csq_cleanup() function.
- Fixes a problem that causes systems to panic with a "kernel memory fault"
from u_dev_lockop(). This has happened when a database tried to memory map
a file.
- Fixes an I/O queue corruption problem that occurs during
normal shut down of SMP systems with AdvFS.
- After a disk error occurs, mirror set switching may not happen soon enough
to ensure high availability, or in some cases may not happen at all.
- Fixes a problem that may occur after a system panics.
The system may hang when trying to do a crash dump.
- Fixes panics that may occur on SMP systems with message:
"simple_lock: time limit exceeded"
- Fixes a problem that occurs when running STREAMS. The system panics
with a kernel memory fault in either osr_run() or osr_reopen().
- HSZ40s are not logging non-retryable errors in the errorlog.
- Provides the following additional event logging by the SCSI/CAM disk driver:
Additional Unit Attention messages, additional details for hard errors
logged after unsuccessful I/O recovery attempts, and provides informational
messages on the progress of recovery events.
- When HSZ50 hardware is installed, the system exhibits very slow performance.
- Eliminates panics that will occur when attempting to execute
shell scripts on a filesystem mounted with the "noexec" option.
- Fixes the corruption of core files produced by applications
with 15 or more threads.
- Fixes two system panics - no special situation that will cause these panics;
they can occur during normal system operations.
o Fixes a panic that prints "pmap_dup: level3 PTE not valid".
o Fixes a panic that prints "kernel memory fault".
- Fixes a problem with the exec() system function where a shell script
that has "#! " as the first line of the script,
invokes the program but does not set the effective user id for
the execution of the program.
- Fixes a problem that occurs on AlphaServer 8200 and 8400 systems
when a processor fails to restart after a user halts the system
by entering "Control-P Control-P" and then typing "continue" on the console.
- Fixes a number of problems relating to signals and POSIX 1003.1b timers in
multithreaded programs running on multiprocessor systems. These problems
can result in missed timer-expiration signals and system crashes.
- Fixes a problem in which the the lastcomm accounting command doesn't print
the "S" flag at appropriate times. This patch also improves the performance
of lastcomm.
- Fixes system panic with "Zombie walks again" panic message.
- The system panics with "ipc_thread_init: reply port allocate" after an
unsuccessful port allocation request.
- An aio application that calls aio_suspend() with a list of control blocks
containing a duplicate address can crash the system if the duplicate aio
request has not completed at the time of the call.
- A system with large shared memory segments and a large number of users may
hang or panic when these users disconnect. The solution here is to make use
of unmanaged memory, granularity hints, and shared level 3 page tables.
- System Panics:
o "thread_depress_wait" on multi-processor machines running
multi-threaded applications.
o "simple lock owned" panic.
o the following kernel memory fault panics:
* generated from procfs_readdir()/uiomove().
* fault_pc is in the u_anon_free() routine.
* in ubc_sync_iodone().
* when a user changes virtual memory (vm) tuning parameters due
to slow performance and reboots the machine.
* generating a message such as: trap: invalid memory read
access from kernel mode
* when system is running a number of processes which is > than
half the value of npid.
* the fault came from malloc or spec_reclaim.
* on systems running System V applications or any user process
compiled with the System V environment, even if System V is
not loaded on the system.
* in simple_lock_B (on multiprocessor system)
* in malloc(), in ttyclose(), ttymodem(), and in k_mem_fault
o "simple_lock_time_violation" panic (problem could also show up
as a kernel memory fault pani).
o "simple_lock: uninitialized lock" or "simple_lock: uninitialized
lock" (panic in STREAMS code which is associated with high
login/logout rates).
o "pmap_remove_lev2: lev3 pte not valid". The system may experience a
data corruption problem.
o "fill_tlsb: - can not translate address of CPU.\n" panic.
o "simple_lock: time limit exceeded" or "cpu_ip_intr: panic request"
(on SMP systems running applications that use POSIX realtime timers).
o "timeout table overflow" panic when Patch OSF350-060 is installed
on multiprocessor system.
o Alphaserver 8400 boot panic occurs if the master cpu is not in slot 0.
o "simple lock owned" or "simple_lock_fault violation" FAA FDDI driver
panics (during restart or re-initialization).
o "u_shm_oop_deallocate: reference count mismatch panic.
o "pmap_remove_range: page wired" panic.
o `lock_write: interrupt level call` panic.
o "xcr_que_insert list corruption"
- Fix memory and process state output from /proc PIOCPSINFO ioctl and SVE ps
command.
- Cannot kill a multithreaded process.
- Processes on a system may block in an uninterruptible state and never run
again. This problem occurs when using NFS loopback mounts.
- User programs can end with a segmentation violation error when trying to
allocate memory that grows in a downward direction. This problem has been
seen with Fortran programs that use automatic arrays, and with C programs
that use the alloca() function.
- A process can hang and a "kill -9" command will not kill it. The ps command
will show the status of the process as "U". This is a rare problem that is
due to a file system timing problem which occurs during an internal sync and
is difficult to reproduce.
- When executing with OSF PALcode revision 1.45, or greater, some floating point
instructions fail.
- POSIX timer problems: corrupted signal queue (SMP panic) and hung sigwait.
- Various Alphaserver 8400 errorlog fixes; SMP platform fix to clear MCES
register on secondary cpus.
- Corrects an SMP/realtime-preemption race condtion in the signal code that
can allow a process stopped in sigsuspend to miss a signal wakeup and
remaining block indefinitely.
- Alphastation 600 5/xxx has reporting/handling problems with single bit ECC
Errors.
- Corrections for Handling Time:
o Fix leap-year February time loss problem.
o Allow clock to properly wrap at end of year when system is powered
down and to prevent clock loosing a day on each reboot during March
of a leap year.
- Multi-processor systems using the AdvFS file system particularly systems also
using AdvFS for the root and usr file systems may experience intermittent
freezing of interactive processes when the system has a moderate to heavy I/O
load.
- Corrects problems in tlb shootdown code:
- Tlbshootdown requests could panic with timeouts because the
other processor(s) do not respond to the interrupt.
- The system may display invalid "tlb invalidate" messages.
- There could be some memory data corruption or a memory fault.
- Other processors in a cluster could have touched memory while
it was being reset.
- In some adverse situtations the SWXCR controller may hang.
- Fixes some hangs that can occur during the "syncing disks..." portion of panic
processing, improves the reliability of getting a dump after a system panic,
and also makes it more likely that AdvFS buffers will be synced to disk after
a system panic.
- Processes can become hung during a system call to table(). Debuggers are
particularly prone to this problem.
- Corrects a problem where a remote user will kill rlogin or telnet and the
server host will have an orphanned login process and rlogind or telnetd
process in sleep state indefinitely. This is seen only with Asian tty (atty)
or any other host which is running c-list rather than STREAMS ttys.
- The Unix kernel crashes during installation if the memory in the system
exceeds 1GB. This has only been seen on Lynx-class systems with greater than
1GB of memory.
PROBLEM: (Patch ID: OSF350-055)
********
A system with large shared memory segments and a large number of users may
hang or panic when these users disconnect. The solution here is to make use of
unmanaged memory, granularity hints, and shared level 3 page tables.
The following is a typical stack trace for this problem. This will be the stack
trace for one of the processes attempting to detatch from the shared memory.
A separate process may time out and panic the system attempting to acquire the
lock held by this process.
> 0 event_timeout(func = 0xfffffc0000459820, arg = 0xffffffffa9d4f220, timeout = 0)
["../../../../src/kernel/arch/alpha/cpu.c":717]
1 simple_lock_miss() ["../../../../src/kernel/arch/alpha/lockprim.s":1086]
2 free(addr = 0xfffffc0000000012, type = 51)
["../../../../src/kernel/bsd/kern_malloc.c":780, 0xfffffc0000406974]
3 delete_pv_entry() ["../../../../src/kernel/arch/alpha/pmap.c":992]
4 pmap_remove_range() ["../../../../src/kernel/arch/alpha/pmap.c":1781]
5 pmap_remove() ["../../../../src/kernel/arch/alpha/pmap.c":1818]
6 u_anon_unmap() ["../../../../src/kernel/vm/u_mape_anon.c":1592]
7 u_shm_unmap() ["../../../../src/kernel/vm/u_mape_shm.c":315]
8 u_map_delete() ["../../../../src/kernel/vm/vm_umap.c":1188]
9 shmdt() ["../../../../src/kernel/bsd/svipc_shm.c":696]
10 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
11 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
_stack_trace[0]_end:
..............................................................................
General Information for editing kernel tuning/configuration parameters in
/etc/sysconfigtab:
This patch implements four separate changes that all contribute to greatly
reducing the shared memory detach time. It will also improve the page fault
handling time and the time needed to attach a shared memory segment after the
initial attach.
1. Granularity Hints for shared memory segments:
************************************************
The granularity hints fix makes use of the granularity hints bits in
the page table entry (PTE) as specified in the Alpha Architecture references.
Granularity hints is a Translation Buffer (TB) optimization that allows
the TB to map more than a single page. Enabling the granularity hints fix
also enables the shared PTE fix.
The granularity hints fix is enabled by setting the "gh-chunks" parameter in
/etc/sysconfigtab. The gh-chunks parameter is the number of 4 Megabyte chunks
reserved at boot time for shared memory use.
edit /etc/sysconfigtab:
vm:
gh-chunks=512
OR
vm:
gh-chunks=0x200
Example: setting gh-chunks to 512 decimal will reserve 2 Gigabytes of physical memory
for shared memory segment use. Those pages will not be usable for any other purpose.
The calculation is:
In decimal: 4194304 * 512 = 2147483648
In Hex: 0x400000 * 0x200 = 0x80000000
NOTE: Memory that is set aside at boot time for shared memory by specifying
a value for gh-chunks will not be used for anything other than shared memory.
Unused memory from this region is not given back to the system.
There is a short sequence of dbx commands that can be used to determine
if there is extra memory (beyond that required by the application) being
allocated at boot time with gh-chunks. The commands are:
# dbx -k /vmunix /dev/mem
(dbx) px &gh_free_counts
0xfffffc0000681748
(dbx) 0xfffffc0000681748/4X
fffffc0000681748: 0000000000000402 0000000000000004
fffffc0000681758: 0000000000000000 0000000000000002
(dbx) q
#
The first number (402) is the hexadecimal number of free 512 page (4MB) chunks,
the second number (4) is the hexadecimal number of free 64 page (512kb) chunks,
the third number (0) is the hexadecimal number of free 8 page (64kb) chunks and
the fourth number (2) is the hexadecimal number of free 1 page (8kb) chunks.
This command should be run while the application, which allocates shared memory,
is running. The size of gh-chunks can be lowered such that there is only a
few (1 or 2) 512 page chunks still free with the application running.
Other vm: /etc/sysconfigtab options you may wish to use:
vm:
gh-min-seg-size=N
# requests (shmget) at or above N bytes will use memory from the gh-chunks
# region. Default is 8388608 bytes.
# if the following flag is set to 1 and the request is larger than
# gh-min-seg-size but there is not enough memory in gh-chunks area
# to satify the request (shmget) then a failure is returned to shmget.
#
# If this flag is zero, then the entire request will be handled in
# the pageable memory area. Default is 1.
vm:
gh-fail-if-no-mem=1
2. Shared PTEs for shared memory segments:
******************************************
The shared PTEs fix enables sharing of Level 3 page table entries in the memory
specified above by gh-chunks, resulting in a substantial savings of system
memory.
To be able to Level 3 PTEs, the shared memory segment attach address
(in the shmat() system call) and the size of the shared memory segment
(in shmget()) must be aligned on an 8 Megabyte boundry. This means that
the lowest 23 bits of the address and size must be zero.
Note 1: The attach address and the total size of the shared memory segment
is specified by the application.
Note 2: System V shared memory semantics allow a maximum shared memory segment
size of (2 GB - 1). Specify a max value of (2Gb - 8mb) in DEC UNIX.
Applications that need shared memory segments larger than 2 GB should
construct such regions by using multiple segments.
The above notes imply that the total shared memory size specified by the user
to the application must be 8 MB aligned. In addition "shm-max", the size
specifying the maximum System V shared memory segment size must be 8 MB aligned.
If the total shared memory size specified to the application is greater than
2 GB, it is reasonable to set "shm-max" as follows:
vm:
ipc:
shm-max=2139095040 ( this is = 2gb - 8mb )
OR
shm-max=0x7f800000
Note 3: This is the maximum value of "shm-max" that will allow sharing of PTEs.
The maximum value for "shm-max value is calculated using the formula:
shm-max = 2GB - 8MB.
There is a dbx command that can be used to determine if PTEs are being shared.
The command is:
dbx -k /vmunix /dev/mem
(dbx) p *(vm_granhint_stats *)&gh_stats_store
struct {
total_mappers = 21
shared_mappers = 21
unshared_mappers = 0
total_unmappers = 21
shared_unmappers = 21
unshared_unmappers = 0
unaligned_mappers = 0
access_violations = 0
unaligned_size_requests = 0
unaligned_attachers = 0
wired_bypass = 0
wired_returns = 0
}
(dbx) q
#
The fields of interest are:
shared_mappers
unshared_mappers
unaligned_attachers
unaligned_size_requests
For best performance you should see:
shared_mappers =
unshared_mappers = 0
unaligned_attachers = 0
unaligned_size_requests = 0
Due to how shared memory gets broken up into shared memory segments, there
may be some unshared segments. This is due to the starting address or the
size not being 8 Megabyte aligned. This may be unavoidable in some cases.
Please Note: In many cases the total_unmappers will be greater than the
number of total_mappers. This is normal behavior.
3. Rework of shared memory locking for better parallelism:
**********************************************************
The shared memory locking rework changes a lock that was a single lock
to a hashed array of locks. The size of the hashed array of locks is
tunable with "vm-page-lock-count" in /etc/sysconfigtab:
vm:
vm-page-lock-count=64
4. Improved Kernel Malloc Garbage Collection
********************************************
There are NO tunable parameters relating to the improved kernel malloc()
garbage collection. This is enabled by default and cannot be disabled.
PROBLEM: (QAR 40933) (Patch ID: OSF350-103)
********
The system may panic if a process is bound to a processor
(e.g., runon 1 ls -lR /) and the processor with the bound job is then halted
(e.g., psradm -f 1). panic: thread_block: simple lock owned.
runon 1 ls -lR / > /dev/null &
psradm -f 1
PROBLEM: (QAR 40991) (Patch ID: OSF350-103)
********
Fixes the panic "thread_depress_wait" on multi-processor machines
running multi-threaded applications.
PROBLEM: (MCPMB3AE6) (Patch ID: OSF350-106)
********
This problem results in a kernel memory fault generating a message such as:
trap: invalid memory read access from kernel mode
faulting virtual address: 0xffffffff80914000
pc of faulting instruction: 0xfffffc00004e6cbc
ra contents at time of fault: 0xfffffc0000444aac
sp contents at time of fault: 0xffffffffa95d70d0
panic (cpu 0): kernel memory fault
where the pc is in uiomove(), and the faulting virtual address would be
the beginning of an unmapped page. Because of the incorrect source
address calculation, uimove() will typically go well beyond the internal
buffer into unmapped territory.
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1717]
1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1215]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
4 bcopy() ["../../../../src/kernel/arch/alpha/fastcopy.s":169]
5 uiomove() ["../../../../src/kernel/bsd/kern_subr.c":96]
6 procfs_readdir() ["../../../../src/kernel/procfs/procfs_vnops.c":2417]
7 mvop_osf1axp_readdir(vp = 0xffffffffa957d2b0, uiop = (nil), cred = 0xffffff
ffa95838f8, eofflagp = (nil)) ["../mfs_mdep_osf1axp.c":2280, 0xffffffffa9599dc4]
8 mfs_readdir() ["../mfs_vnodeops.c":4422]
9 mvfs_osf1axp_readdir() ["../mfs_mdep_osf1axp.c":1021]
10 getdirentries() ["../../../../src/kernel/vfs/vfs_syscalls.c":3170]
11 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
12 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
PROBLEM: (QAR 42141) (Patch ID: OSF350-110)
********
An aio application that calls aio_suspend() with a list of control blocks
containing a duplicate address can crash the system if the duplicate
aio request has not completed at the time of the call.
The stack trace of the crashing thread will have at least the following frames:
0 panic()
1 trap()
2 _XentMM()
3 aio_remove_tests()
4 aio_wait()
5 syscall()
6 _Xsyscall()
PROBLEM: (UVO103764) (Patch ID: OSF350-113)
********
Fixes system panic with "Zombie walks again" panic message.
PROBLEM: (QAR 42447) (Patch ID: OSF350-125)
********
The /proc PIOCPSINFO ioctl returns incorrect data for the pr_state, pr_size, and
pr_rssize fields of struct prpsinfo. The state field may show the process
running (R) when it is in fact sleeping (S). The rss field will consistently
show 0; and the size field will usually significantly underreport the virtual
address size of the process.
These symptoms may be observed directly through the use of the PSINFO ioctl, or
indirectly through the use of the ps command from the System V Environment
(SVE) layered product.
The problem can also cause the SVE gcore command to fail.
PROBLEM: (QAR 43054) (Patch ID: OSF350-126)
********
When a multithreaded process is killed, stopped or otherwise is caused to stop
or exit asynchronously, it hangs. The process goes into an un-interruptible
wait state, typically indicated by a "U" in a ps output. Besides a reboot
there is no other way to remove the process.
A typical stack trace on such a hung process will have a few threads in
the following state:
Thread 0xfffffc0001004c00:
> 0 thread_block() [kern/sched_prim.c":1903]
1 thread_dowait() [kern/thread.c":2065]
waiting on thread 0xfffffc0006eb8000, which is blocked uninterruptibly
for the cluster lock held by thread 0xfffffc0004b5e800 which is already
suspended so won't unlock. (see below).
2 task_dowait() [kern/task.c":804]
3 thread_ex_check() [bsd/kern_proc.c":275]
4 exit() [bsd/kern_exit.c":695]
5 rexit() [bsd/kern_exit.c":635]
6 syscall() [arch/alpha/syscall_trap.c":519]
7 _Xsyscall() [arch/alpha/locore.s":1094]
Thread 0xfffffc0004b5e800:
> 0 thread_block() [kern/sched_prim.c":1903]
1 u_anon_faultpage() [vm/u_mape_anon.c":874]
2 u_anon_fault() [vm/u_mape_anon.c":740]
3 u_map_fault() [vm/vm_umap.c":422]
4 vm_fault() [vm/vm_fault.c":130]
5 trap() [arch/alpha/trap.c":1223]
6 _XentMM() [arch/alpha/locore.s":1307]
Thread 0xfffffc0006eb8000:
> 0 thread_block() [kern/sched_prim.c":1891]
1 u_anon_fault() [vm/u_mape_anon.c":702]
2 u_map_fault() [vm/vm_umap.c":422]
3 vm_fault() [vm/vm_fault.c":130]
4 trap() [arch/alpha/trap.c":1223]
5 _XentMM() [arch/alpha/locore.s":1307]
Thread 0xfffffc0001004400:
> 0 thread_block() [kern/sched_prim.c":1891]
1 u_anon_fault() [vm/u_mape_anon.c":702]
2 u_map_fault() [vm/vm_umap.c":422]
3 vm_fault() [vm/vm_fault.c":130]
4 trap() [arch/alpha/trap.c":1223]
5 _XentMM() [arch/alpha/locore.s":1307]
PROBLEM: (QAR 43968) (Patch ID: OSF350-136)
********
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]
1 panic() [bsd/subr_prf.c":669]
2 event_timeout() [arch/alpha/cpu.c":706]
3 xcpu_puts() [bsd/subr_prf.c":810]
4 printf() [bsd/subr_prf.c":355]
5 panic() [bsd/subr_prf.c":719]
6 trap() [arch/alpha/trap.c":1213]
7 _XentMM() [arch/alpha/locore.s":1307]
8 u_anon_free() [vm/u_mape_anon.c":2261]
9 u_anon_unmap() [vm/u_mape_anon.c":1617]
10 u_map_delete() [vm/vm_umap.c":1188]
11 u_map_deallocate() [vm/vm_umap.c":436]
12 vm_map_deallocate() [vm/vm_map.c":611]
13 task_deallocate() [kern/task.c":472]
14 waitf() [bsd/kern_exit.c":1497]
15 wait4() [bsd/kern_exit.c":1220]
16 syscall() [arch/alpha/syscall_trap.c":519]
17 _Xsyscall() [arch/alpha/locore.s":1094]
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);
}
PROBLEM: (Case ID: ISO100191 qar42778) (Patch ID: OSF350-138)
********
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.
PROBLEM: (MCPMC8AC6) (Patch ID: OSF350-104)
********
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: OSF350-118)
********
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]
PROBLEM: (HPXQ19D0B) (Patch ID: OSF350-134)
********
This problem results in a kernel memory fault generating a message such as:
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000000000
pc of faulting instruction: 0xfffffc0000461344
ra contents at time of fault: 0xfffffc000027e560
sp contents at time of fault: 0xffffffff90fc7350
panic (cpu 1): kernel memory fault
The panic stack trace will pass through procfs_lookup:
0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":698]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355]
5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":719]
6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281]
7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296]
8 simple_lock_B() ["../../../../src/kernel/arch/alpha/lockprim.s":534]
9 procfs_lookup() ["../../../../src/kernel/procfs/procfs_vnops.c":826]
10 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":568]
11 saccess() ["../../../../src/kernel/vfs/vfs_syscalls.c":2253]
12 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":530]
13 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1086]
See above.
Virtually impossible to reproduce.
PROBLEM: (TKTRA1614) (Patch ID: OSF350-134)
********
The system can panic when system is running a number of processes which is
greater than half the value of npid. The panic string is: "kernel memory
fault."
A typical stack trace is:
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620, ...]
1 panic(s = ... = "kernel memory fault")
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281, ]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296, ...]
4 insmntque() ["../../../../src/kernel/vfs/vfs_subr.c":1897, ...]
5 exec_procfs_trace() ["../../../../src/kernel/bsd/kern_exec.c":1183,...]
6 common_exec() ["../.. /../../src/kernel/bsd/kern_exec.c":434, ...]
7 execve() ["../../../../src/kernel/bsd/kern_exec.c":263, ...]
8 syscall() ["../../../../src/kernel/arch/ alpha/syscall_trap.c":565,... ]
9 _Xsyscall() [".. /../../../src/kernel/arch/alpha/locore.s":1086,...]
PROBLEM: (QAR 40131) (Patch ID: OSF350-157)
********
User programs can end with a segmentation violation error when trying to
allocate memory that grows in a downward direction. This problem has been
seen with fortran programs that use automatic arrays, and with C programs
that use the alloca() function.
PROBLEM: (HPAQ316C8, KAOB19A78, UVO104061) (Patch ID: OSF350-170)
********
This patch fixes a system panic "simple_lock_time_violation" where the
O/S lock routine is called by event_post(). The clearalias() routine
will be part of the stack trace involved. A stack trace might look
as follows:
panic
simple_lock_fault
simple_lock_time_violation
event_post
select_wakeup
pse_close
speclose
clearalias
exit
psig
syscall
_Xsyscall
This problem could also show up as a kernel memory fault panic.
PROBLEM: (HGOQ80223, QAR's 40742 42496 40255) (Patch ID: OSF350-141)
********
A process can hang and a "kill -9" command will not kill it.
The ps command will show the status of the process as "U".
This is a rare problem that is due to a file system timing problem
which occurs during an internal sync and is difficult to reproduce.
Running dbx on the hung thread will show getnewvnode and ufs_fsync
on the stack.
A typical stack trace is:
> 0 thread_block() ["src/kernel/kern/sched_prim.c":1911]
1 ufs_fsync_set_wait_flag() ["src/kernel/ufs/ufs_vnops.c":6149]
2 ufs_fsync_int() ["src/kernel/ufs/ufs_vnops.c":1935]
3 ufs_fsync() ["src/kernel/ufs/ufs_vnops.c":2083]
4 getnewvnode() ["src/kernel/vfs/vfs_subr.c":1551]
5 vdealloc() ["src/kernel/vfs/vfs_subr.c":1235]
6 vrele(vp = 0xfffffc000040afb0) ["src/kernel/vfs/vfs_subr.c":2276]
7 vn_close() ["src/kernel/vfs/vfs_vnops.c":1258]
8 closef() ["src/kernel/bsd/kern_descrip.c":1393]
9 close() ["src/kernel/bsd/kern_descrip.c":1071]
10 syscall() ["src/kernel/arch/alpha/syscall_trap.c":519]
11 _Xsyscall() ["src/kernel/arch/alpha/locore.s":1094]
PROBLEM: ( QCABLR030 TKTB27949 35661 ) (Patch ID: OSF350-173)
********
The system panics with "kernel memory fault". The crash dump will show that
the fault came from malloc or spec_reclaim.
In the case of malloc, a message similar to the following will be printed:
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000453940
pc of faulting instruction: 0xfffffc000042ee08
ra contents at time of fault: 0xfffffc000042edec
sp contents at time of fault: 0xffffffffd1ed28b8
The crucial data is the faulting address with 32 high bits of zero,
and 32 low bits of non-zero.
The following is an example of a kernel memory fault panic
coming from malloc:
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1620 ]
1 panic("kernel memory fault")
["../../../../src/kernel/bsd/subr_prf.c":752]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1296]
4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":520]
5 _ms_malloc() ["../../../../src/kernel/msfs/bs/ms_mode.c":144]
...
The following is an example of a kernel memory fault panic coming from
spec_reclaim:
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":2023]
1 panic("kernel memory fault")
["../../../../src/kernel/bsd/subr_prf.c": 757]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1335]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1311]
4 spec_reclaim() ["../../../../src/kernel/vfs/spec_vnops.c":1165]
5 msfsspec_reclaim() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":4254]
...
PROBLEM: (QAR 33741) (Patch ID: OSF350-184)
********
The system panics with "ipc_thread_init: reply port allocate" after
an unsuccessful port allocation request.
A user wrote a program that called port_allocate() repeatedly until
the system ran out of resources. After that the next operation anywhere
on the system that needed those same resources caused the system to panic.
Here is a representative stack trace:
0 boot() [src/kernel/arch/alpha/machdep.c:1735]
1 panic("ipc_thread_init: reply port allocate") [src/kernel/bsd/subr_prf.c:757]
2 ipc_thread_init() [src/kernel/kern/ipc_tt.c:420]
3 thread_create_internal() [src/kernel/kern/thread.c:913]
4 procdup() [src/kernel/vm/vm_unix.c:598]
5 newproc() [src/kernel/bsd/kern_fork.c:672]
6 fork1() [src/kernel/bsd/kern_fork.c:500]
7 vfork() [src/kernel/bsd/kern_fork.c:427]
8 syscall() [src/kernel/arch/alpha/syscall_trap.c:519]
9 _Xsyscall() [src/kernel/arch/alpha/locore.s:1094]
PROBLEM: (QAR 40124) (Patch ID: OSF350-202)
********
When executing with OSF PALcode revision 1.45, or greater, with Digital UNIX
V3.2C some floating point instructions fail.
Some floating point instructions fail and cause the message on the console:
"unknown OPDEC from ieee emulation"
There may also be user output instruction fault messages such as:
"inst fault=4, status word= 8, pc= 3ff80128e50"
"Illegal instruction (core dumped)"
The following table identifies the machines that may have this
problem.
Platform Firmware Minimum Rev
-------- --------------------
DECpc AXP 150 SRM Console V2.2
DEC 2000 AXP SRM Console V2.2
DEC 3000 AXP Console V6.5
DEC 4000 AXP Console V3.7
AlphaStation 2x0/400 SRM Console V6.0
AlphaServer 400 SRM Console X4.4
AlphaStation 255 SRM Console V6.0
AlphaServer 1000/1000A SRM Console V3.1-21
AlphaServer 2000/2100 SRM Console V4.4
DEC 7000/10000 AXP LFU V11
Digital AXPvme Console V15.0
DECAXPPC133 SRM Console X4.3-3114
To determine the revision of the OSF PALcode, do one of the following:
1) Look for the following line in the output from Digital UNIX as it boots.
PALcode: OSF version 1.45
2) At the console prompt prior to booting Digital UNIX, type "show config".
>>>show config
Console V3.7-3 VMS PALcode V5.53A, OSF PALcode V1.45A
Note: V1.45A is the same as V1.45.
Common floating point operations will reproduce the problem. For example:
floor.c
-------
#include
main()
{
double dd = (double)0.019999999552965164;
double int_dd;
int_dd = floor(dd);
printf("dd = %f int_dd = %f\n", dd, int_dd);
}
Compiling with:
---------------
cc floor.c -o floor
Executing:
---------
floor
inst fault=4, status word= 8, pc= 3ff80128e50
Illegal instruction (core dumped)
PROBLEM: ( QAR 36390, QAR 31822 ) (Patch ID: OSF350-203)
********
Fixes panic in STREAMS code which is associated with high login/logout rates.
If running in lockmode=4, the problem typically has
the following stack footprints (if not running in lockmode=4,
random corruption can result)
11 panic("simple_lock: uninitialized lock")
["../../../../src/kernel/bsd/subr_prf.c":757]
12 simple_lock_fault() ["../../../../src/kernel/kern/lock.c":160]
13 simple_lock_valid_violation() ["../../../../src/kernel/kern/lock.c":1627]
14 osr_free() ["../../../../src/kernel/streams/str_sclls.c":227]
15 pse_ioctl() [../../../../src/kernel/streams/str_scalls.c":2157]
16 spec_ioctl() [../../../../src/kernel/vfs/spec_vnops.c":1871]
17 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":233]
18 stat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2297]
19 syscall() ["../../../../src/kernel/arch/alpa/syscall_trap.c":530]
20 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1086]
____or____
5 panic("simple_lock: uninitialized lock") ["../../
6 simple_lock_fault(slp = 0xffffffff8fb89878, state = 18446739675670743232,
7 simple_lock_valid_violation(slp = 0xfffffc0000359888, state = 0, caller =
8 osr_run(osr = 0xffffffff8fb89800) ["../../../../src/kernel/streams/str_syn
9 pse_ioctl(dev = 6291459, cmd = 536892174, data = (nil), fflag = 0, cred =
10 spec_ioctl(0xffffffff8fa92400, 0x2000530e, 0x0, 0x0, 0xffffffff819f1130) [
11 stat1(0xffffffff81abe210, 0xffffffff95a3f8c8, 0xffffffff95a3f8b8, 0xffffff
12 stat(0xffffffff95a3f8b8, 0xffffffff95a3f8c8, 0xfffffc00004ebcc8, 0x2000000
13 syscall(0x140056000, 0x1, 0x1, 0x21, 0x43) ["../../../../src/kernel/arch/a
14 _Xsyscall(0x8, 0x3ff800e5d38, 0x14000ba10, 0x140055934, 0x11ffffa68) ["../
PROBLEM: (7PXB44695) (Patch ID: OSF350-179)
********
The system may experience a panic related to the access of a level three
page table, one of the panic string may be as follows:
`pmap_remove_range: page wired`
The stack trace for this panic is as follows:
panic("pmap_remove_range: page wired")
pmap_remove_range()
pmap_remove()
u_anon_unmap()
u_map_delete()
vm_map_delete()
munmap()
syscall()
PROBLEM: (7PXB44695) (Patch ID: OSF350-179)
********
The system may experience a data corruption problem. There are no specific
stack traces associated with this problem. We have seen this problem
causing a data corruption in the oracle system table. But, the corruption
need not be limited to Oracle and could show up anywhere.
PROBLEM: (Patch ID: OSF350-016) (HPAQ763AD)
********
Fix for panic with the following panic string:
"fill_tlsb: - can't translate address of CPU.\n"
PROBLEM: (Patch ID: OSF350-024) (CFS.32493)
********
On SMP systems running applications that use POSIX realtime timers, the process
queue of delivered signals could become corrupted, causing the processor to loop
forever scanning the signal queue. Because this processor loops holding the
process lock, a thread running on another CPU will eventually experience a
lock-timeout panic attempting to aquire the process lock of the looping process.
The panic messages and stack traces of the affected processors will resemble
the following crash data output:
simple_lock: time limit exceeded
pc of caller: 0xfffffc00004157e0
lock address: 0xfffffc000ed75210
lock info addr: 0xfffffc00006d4680
lock class name: proc.p_lock
current lock state: 0xc00100680041aa75 (cpu=1,pc=0xfffffc000041aa74,busy)
panic (cpu 0): simple_lock: time limit exceeded
Panic cpu:
Note: the lock timeout can occur on any function that tries
to acquire the process lock. This is just one example.
0 boot
1 panic "simple_lock: time limit exceeded"
2 simple_lock_fault
3 simple_lock_time_violation
4 pfind
5 sohasoutofband
.
.
.
Looping cpu:
1 panic "cpu_ip_intr: panic request")
2 cpu_ip_intr
3 _XentInt
4 sigq_enqueue_tail [infinite loop in corrupted signal queue]
5 psignal_internal
6 psx4_tod_expire_sig
7 psx4_tod_expire
8 softclock_scan
9 hardclock
10 _XentInt
PROBLEM: (Patch ID: OSF350-024) (QAR 35597)
********
When POSIX realtime interval timers are awaited with sigwait() or with
sigwaitinfo/sigtimedwait() without a siginfo_t pointer argument, the repetitive
timer expiration fails to wake up the caller. Using a siginfo_t argument
corrected the problem by allowing correct wakeup notification.
PROBLEM: (Patch ID: OSF350-060) (QAR 35419)
********
An Alphaserver 8400 machine check error caused by an uncorrectable double bit
error will not be logged correctly and the system will not crash successfully.
Instead, a 'kernel stack not valid' error will occur after the panic message
and no core dump or errorlog will be saved.
PROBLEM: (Patch ID: OSF350-060) (QAR 35428)
********
Alphaserver 8400 machine check errorlogs for PCI window space read errors
or IBOX timeout errors do not contain a PCIA subpacket or a PCI bus snapshot.
PROBLEM: (Patch ID: OSF350-060) (QAR 33697)
********
On SMP platforms, the MCES register bit 3 (disable correctable processor
errorlogging) is not cleared on any secondary cpus at startup.
PROBLEM: (Patch ID: OSF350-079) (QAR 39990)
********
Fixes "timeout table overflow" panic when Patch OSF350-060 is installed
on multiprocessor system.
PROBLEM: (Patch ID: OSF350-083) (QAR 40197)
********
Panic message will occur at boot time if the master cpu is not in slot 0:
Master cpu at slot x
Created FRU table configuration errorlog packet
panic (cpu x): tlaser: MACHINE CHECK Non-recoverable hardware error
DUMP: No primary swap, no explicit dumpdev.
Nowhere to put header, giving up.
PROBLEM: (Patch ID: OSF350-101)
********
A scan of an SMP/realtime system's processes with the ps command
locates a process that is stopped with a "pause" WCHAN with an
unblocked signal pending. This process is blocked in the sigsuspend
syscall and has missed being awakened by the pending signal. The ps
output for this process might look like this:
# ps -O sig,sigmask,sigcatch,wchan -p 1500
PID PENDING BLOCKED CAUGHT WCHAN
1500 1 0 1 pause
This output shows that process 1500 is blocked in sigsuspend() trying
to catch signal 1 (SIGHUP). The signal is unblocked *and* pending.
This is an incorrect state when it persists indefinitely. Sending this
process a SIGHUP signal from a terminal will clear the blocked state
temporarily, but the problem is likely to recur
PROBLEM: ( QAR 38256 ) ( Patch ID: OSF350-036 )
********
The Alphastation 600 5/xxx has reporting/handling problems with
single bit ECC Errors per the following symptoms:
- Processor detected single bit ECC errors are not logged correctly.
This means that the necessary data needed to isolate this to a failing
memory SIMM is not available to a customer.
- System detected single bit ECC errors are not handled due to the CPU switch
not containing a handler for system detected single bit ECC errors.
This results in either an installation failing or a system hang once a
system detected ecc error occured.
Hardware affected:
Alphastation 600 5/266 (5/300) systems only
Symptoms:
the systems of these problems will be the following:
- incorrect information logged on processor detected ECC errors
- System hang on System Detected single bit Ecc errors
How to reproduce the problem:
- Use an ALCOR system with a single bit ECC error present in it.
Once you run across this error via the use of the bad memory
you will either get an incorrect error log or system hang.
PROBLEM: (Patch ID: OSF350-142)
********
Fix leap-year February time loss problem.
When the system is rebooted after having set the clock with the date
command in March of a leap year, the system clock will lose one day.
PROBLEM: (CLD HPXQ10B7D) (Patch ID: OSF350-212)
********
Systems shut down and powered off prior to Jan 1 will not have correct date
when restarted after the New Year. Also, the clock on systems rebooted during
the month of March of a leap year will loose a day for each reboot.
PROBLEM: (7MPBA0854, QAR 46525, QAR 38394) (Patch ID: OSF350-225)
********
Multi-processor systems using the AdvFS file system particularly systems also
using AdvFS for the root and usr file systems may experience intermittent
freezing of interactive processes when the system has a moderate to heavy I/O
load. The freezing of interactive processes may last from a few seconds to many
minutes but will eventually return to normal. This problem may also occur on
multi-processor systems using the NFS client or graphics sub-systems.
PROBLEM: ( MCPM55057 QAR 46617 ) (Patch ID: OSF350-235-1)
********
This patch is an upgrade/replacement for the FAA FDDI driver and fixes a
halt/restart problem found in the old driver. The old driver could panic
a system with a "simple lock owned" or "simple_lock_fault violation" during
a restart re-initialization.
Typical error messages from the old driver will include the following:
faa0: Network Adapter halted for re-initialization
lock_write: simple lock owned
pc of caller: 0xfffffc0000366ca0
lock address: 0xfffffc007fdf6030
lock info addr: 0xfffffc00006542b0
lock class name: vm_kmap.vm_lock
pcb slock count: 2
panic (cpu x): lock_write: simple lock owned
simple_lock: hierarchy violation
pc of caller: 0xfffffc00004227ec
lock address: 0xfffffc0079e49200
lock info addr: 0xfffffc00006547a0
class already locked: ifqueue.ifq_slock
Typical stack traces from a panic caused by the old driver will include
the following:
panic
lock_fault
lock_write
vm_map_remove
kmem_free
faa_free_buff
faa_reinitialize
faa_error_recovery
or
panic
simple_lock_fault
simple_lock_hierarchy_violation
xnaintr
.
.
.
faa_service_rcv_q
faaintr
faaintr_2
PROBLEM: (MGO102099, MGO102041) (Patch ID: OSF350-242-1)
********
The system will crash with " u_shm_oop_deallocate: reference count mismatch."
A typical stack trace is shown below:
boot
panic
u_shm_oop_deallocate
vm_map_entry_delete
u_map_delete
u_map_lockvas_expand
u_map_enter
shmat
syscall
_Xsyscall
The problem is closely related to processes that use the "plock" system call
in order to lock their text and/or data segments in memory. When such a process
attaches itself to a shared memory segment, the "shmat" system call allocates
the required physical pages and "locks" them in memory. There may be a
resource shortage in this situation if (e.g.) there aren't enough free pages
available.
PROBLEM: (QAR 44102) (Patch ID: OSF350-264)
********
This patch corrects problems in tlb shootdown code:
- Tlbshootdown requests could panic with timeouts because the
other processor(s) do not respond to the interrupt.
- The system may display invalid "tlb invalidate" messages.
- There could be some memory data corruption or a memory fault.
- Other processors in a cluster could have touched memory while
it was being reset.
There is no stack trace available. If you see a panic with a tlb shootdown
timeout panic, where it appears that one processor has posted a tlb shootdown,
but other processors have not responded, then this patch may fix the problem.
It is also possible to see memory data corruption or a memory fault.
The fix for clusters was made as a preemptive fix in conjunction with fixes for
the other problems here. There are no known instances of problems of this type.
This patch is MOST likely to fix the problem if the chip is an EV-5. It MAY fix
the problem if the chip is an EV-45. For older slower chips, lack of this patch
is probably not the problem.
PROBLEM: (HPAQ68777) (Patch ID: OSF350-265)
********
A system can crash with:
panic: "pmap_remove_range: page wired"
if certain kernel functions try to malloc more memory pages than allowed
by the vm configuration parameter vm-vpagemax, which by default is set
to 16384.
While this parameter could be set higher as a temporary workaround, the
proper fix is to install this patch.
A typical stack trace is:
0 stop_secondary_cpu() [src/kernel/arch/alpha/cpu.c:368]
1 panic("event_timeout: panic request") [src/kernel/bsd/subr_prf.c:669]
2 event_timeout() [src/kernel/arch/alpha/cpu.c:725]
3 xcpu_puts() [src/kernel/bsd/subr_prf.c:810]
4 printf() [src/kernel/bsd/subr_prf.c:355]
5 panic("pmap_remove_range: page wired") [src/kernel/bsd/subr_prf.c:719]
6 pmap_remove_range() [src/kernel/arch/alpha/pmap.c:1804]
7 pmap_remove() [src/kernel/arch/alpha/pmap.c:1946]
8 u_anon_unmap() [src/kernel/vm/u_mape_anon.c:1635]
9 u_map_delete() [src/kernel/vm/vm_umap.c:1211]
10 vm_map_delete() [src/kernel/vm/vm_map.c:1214]
11 munmap() [src/kernel/bsd/kern_mman.c:814]
12 syscall() [src/kernel/arch/alpha/syscall_trap.c:519]
13 _Xsyscall() [src/kernel/arch/alpha/locore.s:1094]
PROBLEM: (HPAQ68777) (Patch ID: OSF350-258)
********
This patch fixes a kernel memory fault panic. This panic occurs on systems
running System V applications or any user process compiled with the System V
environment, even if System V is not loaded on the system.
A representative stack trace is:
5 panic("kernel memory fault")subr_prf.c:719
6 trap()trap.c:1243
7 _XentMM()locore.s:1307
8 malloc()kern_malloc.c:743
9 osr_alloc()str_scalls.c:232
10 pse_ioctl()str_scalls.c:1498
11 spec_ioctl()spec_vnops.c:1987
12 syioctl()tty_tty.c:210
13 spec_ioctl()spec_vnops.c:1987
14 vn_ioctl()vfs_vnops.c:1109
15 ioctl_base()sys_generic.c:465
16 ioctl()sys_generic.c:344
17 syscall()syscall_trap.c:519
PROBLEM: (Patch ID: OSF350-014) (tktb70354,QAR35446,hpaq53f5f,QAR34124)
**********
A multiprocessor system panics with kernel memory fault in simple_lock_B
A representative stack trace follows:
0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":306]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":664]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":616]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":802]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":351]
5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":714]
6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1262]
7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1256]
8 simple_lock_B() ["../../../../src/kernel/arch/alpha/lockprim.s":496]
9 pgrp_ref() ["../../../../src/kernel/bsd/kern_proc.c":561]
10 exit() ["../../../../src/kernel/bsd/kern_exit.c":903]
11 rexit() ["../../../../src/kernel/bsd/kern_exit.c":575]
12 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":530]
13 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1046]
PROBLEM: (Patch ID: OSF350-098) (Case ID: UVO103661, HPXQA4050, MGO101764,
******** TKTRA1625, HPXQB9FCB)
This bug causes panic that results in the following console messages:
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000436244
pc of faulting instruction: 0xfffffc0000431148
ra contents at time of fault: 0xfffffc000043112c
sp contents at time of fault: 0xffffffff9aee75b0
panic (cpu 1): kernel memory fault
The panic stack trace can originate from any number of sources, but will
pass through malloc(), which takes a memory fault leading to a panic:
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":698]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355]
5 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":719]
6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1281]
7 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1306]
8 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":520]
9 psignal_indirect_alloc() ["../../../../src/kernel/bsd/kern_sig.c":4524]
10 realitexpire() ["../../../../src/kernel/bsd/kern_time.c":722]
11 softclock_scan() ["../../../../src/kernel/bsd/kern_clock.c":989]
12 hardclock() ["../../../../src/kernel/bsd/kern_clock.c":813]
13 _XentInt() ["../../../../src/kernel/bsd/subr_prf.c":669]
14 idle_thread() ["../../../../src/kernel/kern/sched_prim.c":2811]
Note that the important part of the trace is from frames 0 through 8; the
caller of malloc() is not relevant, and is unrelated to the problem.
This specific bug can be verified by adding the KSEG base address of
0xfffffc0000000000 to the faulting virtual address taken from the
error message above, and determining what the resulting address represents:
(dbx) (0xfffffc0000000000 + 0x0000000000436244)/i
[pgrp_ref:584, 0xfffffc0000436244] bsr r26, simple_unlock(line 273)
(dbx)
If the result is in pgrp_ref() like above, then this fix is the solution.
Another relevant symptom is that the kmembucket chain containing freed
process group structures is corrupted by the faulting virtual address;
This can be verified by noting that the "kb_next" field in kmembuckets[3]
contains the same faulting address:
(dbx) p kmembuckets[3]
struct {
kb_lock = struct {
sl_data = 0x431129
sl_info = 0x0
sl_cpuid = 0x0
sl_lifms = 0x0
}
kb_next = 0x436244
kb_size = 0x80
kb_free = 0x444
kb_total = 0x1240
kb_elmpercl = 0x40
kb_highwat = 0x800
}
There is no known manner of reproducing the problem; however, on systems where
it happens, it is a fairly regular occurance.
PROBLEM: (MCPM359CA) (Patch ID: OSF350-166)
********
The system panics while performing a process group operation with the
following characteristics:
panic: `lock_write: interrupt level call`
pc of caller: 0xfffffc00003eb1e0
lock address: 0xfffffc00005b2770
lock info addr: 0xfffffc0000660180
lock class name: pgrphash_lock
current spl level: 1
required spl level: 0
A typical stack traces would look like this
1 panic
2 event_timeout
3 xcpu_puts
4 printf
5 panic
6 lock_fault (error = "lock_write: interrupt level call")
7 lock_write
8 pgrp_unref
9 psignal_lwc
10 lwc_schedule
.
.
.
or this
1 panic
2 event_timeout
3 simple_lock_miss
4 lock_read
5 pgfind
.
.
.
PROBLEM: (TKTR21634) (Patch ID: OSF350-227)
********
A dangling "s_ttyvp" vnode pointer in a session structure can allow a reference
to the session structure after it has been freed. This corruption eventually
causes a panic in an unrelated malloc() from kmembuckets[2], from which
session structures are allocated. The corruption to the freed session
structure can be identified by looking at the faulting address, which
indicates that the corruption was done in ttyclose():
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000437820
pc of faulting instruction: 0xfffffc00004206b0
ra contents at time of fault: 0xfffffc0000420644
sp contents at time of fault: 0xffffffffa0977420
panic (cpu 10): kernel memory fault
> 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1727]
1 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
2 trap() ["../../../../src/kernel/arch/alpha/trap.c":1219]
3 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
4 malloc() ["../../../../src/kernel/bsd/kern_malloc.c":743]
5 k_mem_grow_pageable() ["../../../../src/kernel/vm/k_mape_mem.c":660]
6 k_map_allocate_paged() ["../../../../src/kernel/vm/vm_kmap.c":1099]
7 kmem_alloc_pageable() ["../../../../src/kernel/vm/vm_kern.c":257]
8 exec_args_allocate() ["../../../../src/kernel/bsd/kern_execargs.c":345]
9 exec_args_copyin() ["../../../../src/kernel/bsd/kern_execargs.c":70]
10 execve() ["../../../../src/kernel/bsd/kern_exec.c":261]
11 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
12 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
(dbx) 0xfffffc0000437820/i
[ttyclose:1336, 0xfffffc0000437820] bsr r26, simple_unlock(line 263)
PROBLEM: (UVO104310) (Patch ID: OSF350-227)
********
A related problem, with respect to the problem reported in case TKTR21634
described above, occurs when ttymodem() uses the "s_leader" field from
the freed session structure:
trap: invalid memory read access from kernel mode
faulting virtual address: 0x0000000000000008
pc of faulting instruction: 0xfffffc0000426314
ra contents at time of fault: 0xfffffc00003dbff0
sp contents at time of fault: 0xffffffff911cf370
panic (cpu 0): kernel memory fault
> 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1900]
1 thread_preempt() ["../../../../src/kernel/kern/sched_prim.c":3450]
2 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1679]
3 panic("kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":757]
4 trap() ["../../../../src/kernel/arch/alpha/trap.c":1213]
5 _XentMM() ["../../../../src/kernel/arch/alpha/locore.s":1307]
6 simple_lock_B() ["../../../../src/kernel/arch/alpha/lockprim.s":524]
7 proc_ref() ["../../../../src/kernel/bsd/kern_proc.c":552]
8 ttymodem() ["../../../../src/kernel/bsd/tty.c":1379]
9 ptcclose() ["../../../../src/kernel/bsd/tty_pty.c":606]
10 speclose() ["../../../../src/kernel/vfs/spec_vnops.c":2193]
11 spec_close() ["../../../../src/kernel/vfs/spec_vnops.c":2341]
12 msfsspec_close() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":3783]
13 vn_close() ["../../../../src/kernel/vfs/vfs_vnops.c":1220]
14 closef() ["../../../../src/kernel/bsd/kern_descrip.c":1393]
15 close() ["../../../../src/kernel/bsd/kern_descrip.c":1071]
16 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":519]
17 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1094]
PROBLEM: (CLD UVO104419) (Patch ID: OSF350-251)
********
This patch fixes a problem in which the system panics with a kernel memory fault
in k_mem_fault. This is caused by a user application that calls one of the
vectored IO system calls and passes an invalid kernel address as one of the
arguments. This invalid address is not properly validated by the kernel and
therefore causes the kernel memory fault.
The typical stack traceback is as follows:
1.) panic(kernel memory fault)
2.) trap()
3.) _XentMM()
4.) k_mem_fault()
5.) k_map_fault()
6.) vm_fault()
7.) trap()
8.) _XentMM
9.) bcopy()
10.) uiomove()
11.) mmrw()
12.) mmread()
13.) spec_read()
14.) msfsspec_read()
15.) vn_read()
16.) rwuio()
17.) read() ../src/kernel/bsd/sys_generic.c
18.) syscall()
PROBLEM: (DMO100161, QAR39130) (Patch ID: OSF350-082)
**********
System panics with "xcr_que_insert list corruption"
Stack trace:
> 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":352]
1 panic("event_timeout: panic request")
["../../../../src/kernel/bsd/subr_prf.c":669]
2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":698]
3 xcpu_puts() ["../../../../src/kernel/bsd/subr_prf.c":810]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":355]
5 panic("xcr_que_insert list corruption")
["../../../../src/kernel/bsd/subr_prf.c":719]
6 xcr_que_insert() ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1222]
7 xcr_action() ["../../../../src/kernel/io/dec/eisa/xcr_port.c":1114]
8 re_ioctl() ["../../../../src/kernel/io/dec/eisa/re_driver.c":2803]
9 spec_ioctl() ["../../../../src/kernel/vfs/spec_vnops.c":1986]
10 vn_ioctl() ["../../../../src/kernel/vfs/vfs_vnops.c":1109]
11 ioctl_base() ["../../../../src/kernel/bsd/sys_generic.c":465]
12 ioctl() ["../../../../src/kernel/bsd/sys_generic.c":344]
13 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":530]
14 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1086]
PROBLEM: (Case ID: QAR 41490 ) (Patch ID: OSF350-135)
********
In some adverse situtations the SWXCR controller may hang. There is a SWXCR
Driver timing issue where a rebuild in process can cause the controller to
delay I/O completion and timeout commands. The driver will start to reset the
controller and eventually the controller will hang. This is evident by the
fact that I/Os issued to that SWXCR controller do not complete. This patch
will correct this problem.
PROBLEM: ( HPXQ43C4D, TKTR52185, QAR 46016 ) (Patch ID: OSF350-277)
********
This patch fixes some hangs that may occur after the message "syncing disks..."
is printed when the system panics. When these hangs occur, the completion of
the "syncing disks..." message - the word "failed" or "done" does not get
printed, and the system does not take a dump.
In addition to fixing these known hangs, a timout mechanism is added to the
"syncing disks" logic that will improve the reliability of getting a dump by
using the system clock to break out of the "syncing disks" path and take
a dump if no progress is being made on reducing the number of buffers to be
flushed. The numbers printed periodically between the "syncing disks..."
and "done" messages are the number of buffers left to flush.
This patch also makes it more likely that AdvFS buffers will be flushed to
disk during the "syncing disks..." processing after a system panic. There
is still no guarantee that writes in progress at the time of a panic will be
completed.
PROBLEM: (CA6Q61192,UVO104419 ) (Patch ID: OSF350-280)
********
Processes can become hung during a system call to table(). Debuggers are
particularly prone to this problem.
PROBLEM: ( TKTR70408 ) (Patch ID: OSF350-284)
********
This problem affects only Digital UNIX systems using C-list-type tty's. If a
user attempts to log into such a system remotely, using either telnet or rlogin,
and kills the remote-access application (telnet or rlogin) during the login
procedure (at the "Password:" prompt) then the rlogind or telnetd process will
be left in a sleep state indefinitely. This condition can be recognized by the
presense of rlogind or telnetd processes in the process table with no associated
remote user.
PROBLEM: (EMZB83716, QAR 48019) (Patch ID: OSF350-290)
********
The Unix kernel crashes during installation if the memory in the system
exceeds 1GB. This has only been seen on Lynx-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: (HPXQ87202,QAR 49448,QAR 49474,QAR 49475,QAR 49553)
******** (Patch ID: OSF350-295)
This patch fixes a problem in which the the lastcomm accounting command
doesn't print the "S" flag at appropriate times. This patch also improves
the performance of lastcomm.
The problem was that the kernel did not properly update the accounting field
that prints the "S" flag. The "S" flag should be printed for each command
that is run with an effective user id of 0. Commands that are set-user-id
to root, will print the "S" flag. Also, commands that are executed by root,
but are not set-user-id, will print the "S" flag. Therefore, when "S" is
printed from lastcomm for a certain command, it means that the user had
root privileges at some time during the execution of the command.
The algorithm used by lastcomm has been enhanced to improve its performance.
PROBLEM: (QARs 49942 & 49814) (Patch ID: OSF350-321)
********
This patch fixes a problem that causes the system to panic with a
kernel memory fault or "malloc_audit: guard space corruption"
with osr_run as an entry in the stack.
At this time no additional stack information is available.
PROBLEM: (MGO102628,MGO102687,QAR 51439) (Patch ID: OSF350-360-1)
*******
When debugging multithreaded applications with Ladebug, debugging sessions
may hang due to a bug in procfs (i.e., /proc filesystem).
A simple way to reproduce the problem is to set a breakpoint in separate
threads, run the application, change the thread focus to a thread other than
the one which took the breakpoint, and to single-step. Under these
circumstances, the debugger does not return to the debugger prompt
and the debugging session effectively hangs. At this point, ps output
simply indicates that the debugger and the debuggee are sleeping interruptibly.
However, when a SIGKILL is sent to the debuggee, the affected threads o
in the debugged process enter an uninterruptible sleep ('U' state in
the ps listing). The traced process is now unkillable.
PROBLEM: (QAR 50697,MGO102332,FNO100130) (Patch ID: OSF350-369)
*******
This patch fixes a number of problems relating to signals and
POSIX 1003.1b timers in multithreaded programs running on multiprocessor
systems. These problems can result in missed timer-expiration signals
and system crashes. These issues involve synchronizing timer creation,
timer deletion, and timer reset within multithreaded programs.
Two distinct crashes are typical of the problems.
Here's a sample of the first crash, a signal panic:
panic (cpu 0): psig: catch not set
With the following stack trace:
> 0 boot
1 panic
2 psig
3 syscall
4 _Xsyscall
A sample of the second crash is shown in the following example:
from vmcore.3 :
.
.
.
simple_lock: time limit exceeded
.
.
.
pc of caller: 0xfffffc000024a5a4
lock address: 0xfffffc003d93b210
current lock state: 0x000000000043af85
(cpu=0,pc=0xfffffc000043af84,busy)
.
.
.
panic (cpu 2): simple_lock: time limit exceeded
While a stack trace would show:
kernel stack of CPU 0
> 0 boot
1 panic
2 event_timeout
3 simple_lock_miss
4 netisr_timeout
5 softclock_scan
6 lwc_schedule
7 thread_preempt
8 boot
9 panic
10 cpu_ip_intr
11 _XentInt
12 swap_ipl_preempt_check
13 wanTimerSysTick
.
.
.
kernel stack of CPU 1
> 0 stop_secondary_cpu ...
1 panic :
2 cpu_ip_intr : THIS PART OF THE KERNEL STACK
3 _XentInt : IS VERY TYPICAL FOR THIS CLASS
4 sigq_enqueue_tail : OF CRASHES.
5 psignal_internal :
6 psx4_tod_expire_sig ..:
7 psignal_lwc
8 lwc_schedule
9 do_preemption
10 simple_unlock_preempt
11 sigwaitprim
12 syscall
13 _Xsyscall
.
.
.
kernel stack of CPU 2
> 0 stop_secondary_cpu
1 panic
2 event_timeout
3 xcpu_puts
4 printf
5 panic
6 simple_lock_fault
7 simple_lock_time_violation
8 psx4_set_todtimer
9 syscall
10 _Xsyscall
.
.
.
kernel stack of CPU 3
> 0 stop_secondary_cpu
1 panic
2 cpu_ip_intr
3 _XentInt
4 swap_ipl_preempt_check
5 netisr_thread
6 wanTimerTick
.
.
.
This patch closes MP race conditions for multithreaded use of POSIX
timers and signals.
PROBLEM: (GOZ100707,MCPM777CC,QAR 47889,48876) (Patch ID: OSF350-371)
********
This patch fixes a problem that occurs on AlphaServer 8200 and 8400 systems
when a processor fails to restart after a user halts the system by entering
"Control-P Control-P" and then typing "continue" on the console.
This patch requires running firmware version 4.8-6 or later.
This patch also fixes a problem where the pset_info and psradm commands
fail to correctly report that a CPU is shut down.
PROBLEM: (QAR 50693, QAR 49421) (Patch ID: OSF350-372)
********
This patch corrects a problem with the exec() system function.
A shell script that has "#! " as the first line
of the script, invokes the program but does not set the effective user id
for the execution of the program.
PROBLEM: (QAR 42473) (Patch ID: OSF350-376)
********
Fixes a panic that prints "pmap_dup: level3 PTE not valid".
A typical stack trace is:
1 panic("pmap_dup: level3 PTE not valid")
2 pmap_dup() [src/kernel/arch/alpha/pmap.c]
3 vm_dup_va() [src/kernel/vm/vm_kern.c]
4 alloc_context() [src/kernel/io/dec/ws/interg.c]
5 interg_ioctl() [src/kernel/io/dec/ws/interg.c]
6 wsioctl() [src/kernel/io/dec/ws/ws_driver.c]
7 spec_ioctl() [src/kernel/vfs/spec_vnops.c]
8 vn_ioctl() [src/kernel/vfs/vfs_vnops.c]
9 ioctl_base() [src/kernel/bsd/sys_generic.c]
10 ioctl() [src/kernel/bsd/sys_generic.c]
11 syscall() [src/kernel/arch/alpha/syscall_trap.c]
12 _Xsyscall() [src/kernel/arch/alpha/locore.s]
PROBLEM: (QAR 51581) (Patch ID: OSF350-376)
********
Fixes a panic that prints "kernel memory fault".
A typical stack trace is:
1 panic("kernel memory fault")
2 trap() [src/kernel/arch/alpha/trap.c]
3 _XentMM() [src/kernel/arch/alpha/locore.s]
4 bcopy() [src/kernel/arch/alpha/fastcopy.s]
5 volkiocopyin() [src/kernel/lsm/dec/kiosubr.c]
6 volsio_stabilize() [src/kernel/lsm/common/stable.c]
7 vol_mv_write_start() [src/kernel/lsm/common/mvio.c]
8 volkiostart() [src/kernel/lsm/common/kiostart.c]
9 volstrategy() [src/kernel/lsm/dec/voldev.c]
10 physio() [src/kernel/ufs/ufs_physio.c]
11 physiock() [src/kernel/lsm/dec/Space.c]
12 volrdwr() [src/kernel/lsm/dec/voldev.c]
13 volwrite() [src/kernel/lsm/dec/voldev.c]
14 spec_write() [src/kernel/vfs/spec_vnops.c]
15 msfsspec_write() [src/kernel/msfs/osf/msfs_vnops.c]
16 vn_write() [src/kernel/vfs/vfs_vnops.c]
17 rwuio() [src/kernel/bsd/sys_generic.c]
18 write() [src/kernel/bsd/sys_generic.c]
19 syscall() [src/kernel/arch/alpha/syscall_trap.c]
20 _Xsyscall() [src/kernel/arch/alpha/locore.s]
PROBLEM: (USG-04712) (Patch ID: OSF350-379)
********
The patch fixes the corruption of core files produced by applications
with 15 or more threads.
The corrupted core file will show nonsensical or incomplete stack traces
beyond the fifteenth thread. The register and local variable state
of threads can also show incorrect values.
PROBLEM: (Patch ID: OSF350-438-1)
********
This patch fixes a problem in which panics will occur if an attempt is
made to run a shell script residing on any filesystem mounted with
the "noexec" option.
The panic message is "kernel memory fault" and the kernel stack trace
obtained from the resulting dump is of the following form:
0 boot
1 panic ("kernel memory fault")
2 trap
3 exec_setuid
4 common_exec
5 execve
6 syscall
7 _Xsyscall
PROBLEM: (MCPMA8909) (Patch ID: OSF350-309)
********
When HSZ50 hardware is installed without this patch, the system can exhibit
very slow performance. This happens because the HSZ50 is not defined in
cam_data.c and devio.h, and the system does not take advantage of its
more advanced capabilities.
PROBLEM: (HPAL21E6A) (Patch ID: OSF350-182)
********
This patch fixes the problem where hsz40's are not logging non-retryable
errors in the errorlog. These errors can be observed by hooking a
printer
to the HSZ40 port and running the FMU utility to display the errors.
PROBLEM: (ZPOB91873, HGOBB0092) (Patch ID: OSF350-366)
********
This patch provides additional event logging of Unit Attention messages
by the SCSI/CAM disk driver to the binary.errlog file.
It also provides additional details for hard errors logged after
unsuccessful I/O recovery attempts, and provides informational
messages on the progress of recovery events.
With this patch, Unit Attention messages are logged if they are received during:
a) Attempts to bring a drive online
b) Sense data requests for reads and writes
c) Recovery from a failed Test Unit Ready command
PROBLEM: (CLD TKTQ42309) (Patch ID: OSF350-403)
********
This patch fixes a problem that occurs when running STREAMS.
The system panics with a kernel memory fault in osr_run().
The kernel memory fault is a result of a non_cloned STREAMS device closing
and not being removed from the hash table.
A sample stack trace is shown as follows:
0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":1923,]
1 thread_preempt()
2 boot()
3 panic(s 0xfffffc000074a020 = "kernel memory fault")
4 trap() ["../../../../src/kernel/arch/alpha/trap.c":1243,]
5 _XentMM()
6 osr_run() ["../../../../src/kernel/streams/str_synch.c":161,]
7 pse_open() ["../../../../src/kernel/streams/str_scalls.c":660,]
8 spec_open() ["../../../../src/kernel/vfs/spec_vnops.c":1249,]
9 vn_open() ["../../../../src/kernel/vfs/vfs_vnops.c":568,]
10 copen() ["../../../../src/kernel/vfs/vfs_syscalls.c":1824,]
11 open() ["../../../../src/kernel/vfs/vfs_syscalls.c":1781,]
PROBLEM: (CLD TKTB37284) (Patch ID: OSF350-403)
********
This patch fixes a problem that occurs when running STREAMS.
The system panics with a kernel memory fault in osr_reopen().
The kernel memory fault is a result of a non_cloned STREAMS device closing
and not being removed from the hash table.
A sample stack trace is shown as follows:
0 boot()
1 panic()
2 trap()
3 _XentMM()
4 osr_reopen()
5 osr_run()
6 pse_open()
7 spec_open()
8 vn_open()
9 copen()
10 open()
PROBLEM: (ZPOB54023) (Patch ID: OSF350-405)
********
This is a mandatory patch for SMP systems.
This patch fixes panics that may occur on SMP systems.
The panics occur when one processor is exiting and the other processor
is trying to perform a pmap_tbsync.
The following error message is displayed on the systems:
"simple_lock: time limit exceeded"
A sample stack trace for the cpu panicking with
"simple_lock: time limit exceeded" is as follows:
panic("simple_lock: time limit exceeded")
simple_lock_fault() ["/src/kernel/kern/lock.c":2065]
simple_lock_time_violation() ["/src/kernel/kern/lock.c":2135]
psignal_internal() ["/src/kernel/bsd/kern_sig.c":3183]
psignal_inthread() [/src/kernel/bsd/kern_sig.c":4235]
exit() ["/src/kernel/bsd/kern_exit.c":1270 ]
rexit()["/src/kernel/bsd/kern_exit.c":755 ]
syscall() ["/src/kernel/arch/alpha/syscall_trap.c":540]
_Xsyscall()[/src/kernel/arch/alpha/locore.s":1209]
A sample stack trace for the cpu performing a pmap_tbsync is as follows:
cpu_ip_intr() ["/src/kernel/arch/alpha/cpu.c":647]
_XentInt()["/src/kernel/arch/alpha/locore.s":1076]
mb()["/src/kernel/arch/alpha/pal_lib.s":252]
xcpu_puts_ipir() ["/src/kernel/bsd/subr_prf.c":866]
event_timeout()["/src/kernel/arch/alpha/cpu.c":1003]
pmap_update_send()["/src/kernel/arch/alpha/pmap_update.c":250]
pmap_tbsync()["/src/kernel/arch/alpha/pmap.c":4151]
pmap_remove_range()["/src/kernel/arch/alpha/pmap.c":2175]
pmap_remove()["/src/kernel/arch/alpha/pmap.c":2310]
pmap_protect()["/src/kernel/arch/alpha/pmap.c":2374]
free()["/src/kernel/bsd/kern_malloc.c":1129]
m_free()["/src/kernel/bsd/uipc_mbuf.c":520"]
m_freem()["/src/kernel/bsd/uipc_mbuf.c":529"]
xnaread()["/src/kernel/io/dec/netif/if_xna.c":1372"]
_XentInt()["/src/kernel/arch/alpha/locore.s":1049]
issig() ["/src/kernel/bsd/kern_sig.c":4678]
mpsleep()["/src/kernel/bsd/kern_synch.c":581]
sigsuspend() ["/src/kernel/bsd/kern_sig.c":2228]
syscall()["/src/kernel/arch/alpha/syscall_trap.c":540"]
_Xsyscall()["/src/kernel/arch/alpha/locore.s":1209]
PROBLEM: (ZPOB54022) (Patch ID: OSF350-408)
********
This patch fixes a problem that may occur after a system panics.
The system may hang when trying to do a crash dump. The problem is
due to the system getting into a boot/panic loop.
The following is an example of a typical stack trace:
1 panic("event_timeout: panic request")
2 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005]
3 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
4 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":1220"]
5 drvr_flush()["/src/kernel/io/common/driver_support.c":2115"]
6 boot()["/src/kernel/arch/alpha/machdep.c":2525]
7 panic("event_timeout: panic request")
8 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"]
9 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
10 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115]
11 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"]
12 boot()["/src/kernel/arch/alpha/machdep.c":2525]
13 panic("event_timeout: panic request")
14 event_timeout()["/src/kernel/arch/alpha/cpu.c":1005"]
15 simple_lock_miss()["/src/kernel/arch/alpha/lockprim.s":1244]
16 re_flush()["/src/kernel/io/dec/eisa/re_driver.c":2115]
17 drvr_flush()[/src/kernel/io/common/driver_support.c":2115"]
18 boot()["/src/kernel/arch/alpha/machdep.c":2525]
PROBLEM: (QAR 51268) (Patch ID: OSF350-427)
********
After a disk error occurs, mirror set switching may not happen soon enough
to ensure high availability, or in some cases may not happen at all.
The problem is that the timeout and retry mechanisms that go into action
after a disk failure prevent prompt notification of LSM that there was an error.
PROBLEM: (QAR 47628,QAR 45627,QAR 45069) (Patch ID: OSF350-430)
********
This patch fixes an I/O queue corruption problem that occurs during
normal shut down of SMP systems with AdvFS.
PROBLEM: (UVO105527) (Patch ID: OSF350-435)
********
This patch fixes a problem that causes systems to panic with
a "kernel memory fault" from u_dev_lockop().
This has happened when a database tried to memory map a file.
A typical stack trace follows:
5 panic("kernel memory fault") [src/kernel/bsd/subr_prf.c:753]
6 trap() [src/kernel/arch/alpha/trap.c:1512]
7 _XentMM() [src/kernel/arch/alpha/locore.s:1424]
8 u_dev_lockop() [src/kernel/vm/u_mape_dev.c:535]
9 u_dev_unmap() [src/kernel/vm/u_mape_dev.c:481]
10 u_map_delete() [src/kernel/vm/vm_umap.c:1321]
11 u_dev_create() [src/kernel/vm/u_mape_dev.c:202]
12 spec_mmap() [src/kernel/vfs/spec_vnops.c:2962]
13 smmap() [src/kernel/bsd/kern_mman.c:831]
14 syscall() [src/kernel/arch/alpha/syscall_trap.c:540]
15 _Xsyscall() [src/kernel/arch/alpha/locore.s:1209]
kernel_memory_fault_data:
faulting virtual address: 0x001ffc003568af9c
pc of faulting instruction: 0xfffffc000042dd4c
ra contents at time of fault: 0xfffffc000042dcb8
sp contents at time of fault: 0xffffffffa9243600
PROBLEM: (CLD MGO102730) (Patch ID: OSF350-440)
********
This patch fixes the problem of a system hang due to corruption of
a STREAM synchronization queue's forward pointer. The system hangs
in the csq_cleanup() function.
A sample stack trace is as follows:
csq_cleanup
osr_pop_subr
osr_close_subr
pse_close
speclose
spec_close
vn_close
closef
close
syscall
PROBLEM: (Patch ID: OSF350-442)
********
This patch provides general support for Version A11 KZPSA firmware.
PROBLEM: (MCSM80GC5) (Patch ID: OSF350-448)
********
This patch fixes a problem that occurs when starting up a system
that is running the auditing subsystem and the performance manager.
The system panics with the following error message:
kernel memory fault
A sample stack trace is shown in the following example:
0 thread_block()
1 thread_preempt()
2 boot()
3 panic(s = 0xfffffc000060b280 = "kernel memory fault")
4 trap()
5 _XentMM()
6 syscall()
7 _Xsyscall()
PROBLEM: (USG-04861) (Patch ID: OSF350-456)
********
This patch fixes the CAM disk subsystem to allow fast recovery from disk errors.
PROBLEM: (CLD TKTBC1151, QAR 52003) (Patch ID: OSF350-460)
*******
This patch fixes a system panic in cdisk_act_mon_thread().
The system will panic with the following panic string:
"event_timeout: panic request".
A representative stack trace is:
> 0 stop_secondary_cpu(do_lwc = 0) ["../../../../src/kernel/arch/alpha/cpu.c": 522, 0xfffffc0000455c10]
1 panic(s = 0xfffffc000067ba18 = "event_timeout: panic request") ["../../../../src/kernel/bsd/subr_prf.c":716, 0xfffffc000027cffc]
2 event_timeout(func = 0xfffffc000027d260, arg = 0xfffffc000071bf70) |["../../../../src/kernel/arch/alpha/cpu.c":1070, 0xfffffc0000456a78]
3 xcpu_puts(s = 0xffffffff8fb43500, prfbufp = 0xfffffc000071bf70) ["../../../../src/kernel/bsd/subr_prf.c":860, 0xfffffc000027d2c4]
4 printf() ["../../../../src/kernel/bsd/subr_prf.c":388, 0xfffffc000027c690]
5 panic(s = 0xfffffc000067e8d0 = "kernel memory fault") ["../../../../src/kernel/bsd/subr_prf.c":769, 0xfffffc000027d178]
6 trap() ["../../../../src/kernel/arch/alpha/trap.c":1574, 0xfffffc0000466e7c]
7 _XentMM(0x4, 0xfffffc00004a896c, 0xfffffc00006ed340, 0xfffffc0000764738, 0x49490a) ["../../../../src/kernel/arch/alpha/locore.s":1441, 0xfffffc000045b374]
8 cdisk_act_mon_thread() ["../../../../src/kernel/io/cam/cam_disk.c":21093, 0xfffffc00004a8968]
PROBLEM: (MCPM94D74, QAR 49067) (Patch ID: OSF350-462)
********
This patch fixes a system crash when setting the date for SMP systems.
A representative stack trace follows:
panic("resettodr: cpu not master")
["../../../../src/kernel/bsd/subr_prf.c":753 ,]
resettodr() ["../../../../src/kernel/arch/alpha/clock.c":322,]
setthetime() ["../../../../src/kernel/bsd/kern_time.c":543,]
settimeofday() ["../../../../src/kernel/bsd/kern_time.c":499,]
FILE(s):
/usr/bin/lastcomm subset OSFBASE350
CHECKSUM: 62225 24 RCSfile: lastcomm.c RCS: 4.2.17.2
/usr/sys/BINARY/alpha_init.o subset OSFHWBIN350
CHECKSUM: 32753 65 RCSfile: alpha_init.c RCS: 1.2.82.4
/usr/sys/BINARY/cam_disk.o subset OSFHWBIN350
CHECKSUM: 41311 206 RCSfile: cam_disk.c RCS: 1.1.402.2
/usr/sys/BINARY/clock.o subset OSFHWBIN350
CHECKSUM: 05819 6 RCSfile: clock.c RCS: 1.2.27.3
/usr/sys/BINARY/contig_malloc.o subset OSFBIN350
CHECKSUM: 18786 9 RCS: 1.1.6.2
/usr/sys/BINARY/cpu.o subset OSFBIN350
CHECKSUM: 30729 62 RCSfile: cpu.c RCS: 1.1.48.5
/usr/sys/BINARY/cpusw.o subset OSFHWBIN350
CHECKSUM: 21667 12 RCS: 1.1.85.2
/usr/sys/BINARY/ds1386clock.o subset OSFHWBIN350
CHECKSUM: 61767 7 RCSfile: ds1386clock.c RCS: 1.1.13.2
/usr/sys/BINARY/fp_ieee_handler.o subset OSFHWBIN350
CHECKSUM: 22616 7 RCSfile: fp_ieee_handler.c RCS: 1.1.22.2
/usr/sys/BINARY/host.o subset OSFBIN350
CHECKSUM: 14120 7 RCSfile: host.c RCS: 4.2.16.2
/usr/sys/BINARY/if_faa.o subset OSFHWBIN350
CHECKSUM: 56180 49 RCSfile: if_faa.c RCS: 1.1.14.2
/usr/sys/BINARY/init_main.o subset OSFBIN350
CHECKSUM: 46930 74 RCSfile: init_main.c RCS: 4.3.157.4
/usr/sys/BINARY/ipc_kport.o subset OSFBIN350
CHECKSUM: 18019 8 RCSfile: ipc_kport.c RCS: 4.3.13.2
/usr/sys/BINARY/ipc_tt.o subset OSFBIN350
CHECKSUM: 05933 10 RCSfile: ipc_tt.c RCS: 4.3.29.2
/usr/sys/BINARY/k_mape_mem.o subset OSFBIN350
CHECKSUM: 31038 16 RCsfile: k_mape_mem.c RCS: 1.1.39.2
/usr/sys/BINARY/kern_aio.o subset OSFBIN350
CHECKSUM: 41395 27 RCSfile: kern_aio.c RCS: 1.1.61.2
/usr/sys/BINARY/kern_clock.o subset OSFBIN350
CHECKSUM: 17035 67 RCSfile: kern_clock.c RCS: 4.3.93.2
/usr/sys/BINARY/kern_exec.o subset OSFBIN350
CHECKSUM: 62995 15 RCSfile: kern_exec.c RCS: 4.5.69.4
/usr/sys/BINARY/kern_exit.o subset OSFBIN350
CHECKSUM: 08235 17 RCSfile: kern_exit.c RCS: 4.4.108.3
/usr/sys/BINARY/kern_fork.o subset OSFBIN350
CHECKSUM: 54303 10 RCSfile: kern_fork.c RCS: 4.4.77.2
/usr/sys/BINARY/kern_malloc.o subset OSFBIN350
CHECKSUM: 06590 80 RCS: 1.1.27.2
/usr/sys/BINARY/kern_proc.o subset OSFBIN350
CHECKSUM: 42321 16 RCSfile: kern_proc.c RCS: 4.3.29.6
/usr/sys/BINARY/kern_prot.o subset OSFBIN350
CHECKSUM: 25119 17 RCSfile: kern_prot.c RCS: 4.4.59.2
/usr/sys/BINARY/kern_sigsend.o subset OSFBIN350
CHECKSUM: 55921 9 RCSfile: kern_sigsend.c RCS: 1.1.13.2
/usr/sys/BINARY/kern_sig.o subset OSFBIN350
CHECKSUM: 40109 43 RCSfile: kern_sig.c RCS: 4.5.99.7
/usr/sys/BINARY/kern_sigqueue.o subset OSFBIN350
CHECKSUM: 20141 8 RCSfile: kern_sigqueue.c RCS: 1.1.29.2
/usr/sys/BINARY/kern_synch.o subset OSFBIN350
CHECKSUM: 19483 9 RCSfile: kern_synch.c RCS: 4.3.48.2
/usr/sys/BINARY/kern_time.o subset OSFBIN350
CHECKSUM: 29618 22 RCSfile: kern_time.c RCS: 4.4.89.2
/usr/sys/BINARY/kernargs.o subset OSFHWBIN350
CHECKSUM: 55468 3 RCS: 1.2.16.2
/usr/sys/BINARY/kn15aa.o subset OSFHWBIN350
CHECKSUM: 48575 39 RCSfile: kn15aa.c RCS: 1.1.89.2
/usr/sys/BINARY/kn16aa.o subset OSFHWBIN350
CHECKSUM: 40046 35 RCSfile: kn16aa.c RCS: 1.1.72.2
/usr/sys/BINARY/kn20aa.o subset OSFHWBIN350
CHECKSUM: 43362 32
/usr/sys/BINARY/kn430.o subset OSFHWBIN350
CHECKSUM: 54002 65
/usr/sys/BINARY/kn8ae.o subset OSFHWBIN350
CHECKSUM: 44278 31 RCSfile: kn8ae.c RCS: 1.1.26.5
/usr/sys/BINARY/kn7aa.o subset OSFHWBIN350
CHECKSUM: 08700 40 RCSfile: kn7aa.c RCS: 1.1.51.5
/usr/sys/BINARY/kn450.o subset OSFHWBIN350
CHECKSUM: 57444 56 RCSfile: kn450.c RCS: 1.1.105.3
/usr/sys/BINARY/kn470.o subset OSFHWBIN350
CHECKSUM: 23875 17 RCS: 1.1.9.4
/usr/sys/BINARY/lsbmem.o subset OSFHWBIN350
CHECKSUM: 29518 3 RCS: 1.2.18.2
/usr/sys/BINARY/lwc.o subset OSFBIN350
CHECKSUM: 12893 6 RCSfile: lwc.c RCS: 1.1.17.2
/usr/sys/BINARY/mach_signal.o subset OSFBIN350
CHECKSUM: 45306 5 RCSfile: mach_signal.c RCS: 4.3.9.2
/usr/sys/BINARY/machdep.o subset OSFHWBIN350
CHECKSUM: 63928 46 RCSfile: machdep.c RCS: 1.2.179.6
/usr/sys/BINARY/machine.o subset OSFBIN350
CHECKSUM: 25964 12 RCSfile: machine.c RCS: 4.3.21.3
/usr/sys/BINARY/mc146818clock.o subset OSFHWBIN350
CHECKSUM: 07375 7 RCSfile: mc146818clock.c RCS: 1.1.21.2
/usr/sys/BINARY/nofault.o subset OSFHWBIN350
CHECKSUM: 26082 3 RCS: 1.1.18.3
/usr/sys/BINARY/pmap.o subset OSFHWBIN350
CHECKSUM: 09926 119 RCSfile: pmap.c RCS: 1.2.140.8
/usr/sys/BINARY/pmap_init.o subset OSFBIN350
CHECKSUM: 57866 14 RCS: 1.1.24.2
/usr/sys/BINARY/pmap_update.o subset OSFBIN350
CHECKSUM: 26293 7 RCS: pmap_update.c Revision: 1.1.36.2
/usr/sys/BINARY/pr.o subset OSFHWBIN350
CHECKSUM: 11708 128 RCS: pr.c Revision: 1.2.75.2
/usr/sys/BINARY/procfs_subrs.o subset OSFBIN350
CHECKSUM: 49475 18 RCSfile: procfs_subrs.c RCS: 1.1.53.3
/usr/sys/BINARY/procfs_vnops.o subset OSFBIN350
CHECKSUM: 10482 111 RCSfile: procfs_vnops.c RCS: 1.1.73.8
/usr/sys/BINARY/re_driver.o subset OSFHWBIN350
CHECKSUM: 21028 30 RCSfile: re_driver.c RCS: 1.1.21.4
/usr/sys/BINARY/sched_prim.o subset OSFBIN350
CHECKSUM: 41329 84 RCSfile: sched_prim.c RCS: 4.3.102.5
/usr/sys/BINARY/sim_pza.o subset OSFHWBIN350
CHECKSUM: 21617 17 RCSfile: sim_pza.c Revision: 1.1.65.2
/usr/sys/BINARY/sim_xpt.o subset OSFHWBIN350
CHECKSUM: 11554 13 RCSfile: sim_xpt.c RCS: 1.1.82.2
/usr/sys/BINARY/softfp.o subset OSFHWBIN350
CHECKSUM: 34288 8 RCSfile: softfp.c RCS: 1.1.16.2
/usr/sys/BINARY/spec_vnops.o subset OSFBIN350
CHECKSUM: 10965 36 RCSfile: spec_vnops.c RCS: 4.4.112.4
/usr/sys/BINARY/startup.o subset OSFHWBIN350
CHECKSUM: 07834 90 RCS: 1.2.41.2
/usr/sys/BINARY/str_runq.o subset OSFBIN350
CHECKSUM: 44262 64 RCSfile: str_runq.c RCS: 4.2.24.2
/usr/sys/BINARY/str_scalls.o subset OSFBIN350
CHECKSUM: 25473 94 RCSfile: str_scalls.c RCS: 4.2.78.6
/usr/sys/BINARY/str_tty.o subset OSFBIN350
CHECKSUM: 56316 9 RCSfile: str_tty.c RCS: 4.2.24.3
/usr/sys/BINARY/svc.o subset OSFBIN350
CHECKSUM: 61564 11 RCSfile: svc.c RCS: 1.1.8.3
/usr/sys/BINARY/svipc_ipc.o subset OSFBIN350
CHECKSUM: 60923 6 RCS: 4.3.26.2
/usr/sys/BINARY/svipc_shm.o subset OSFBIN350
CHECKSUM: 41401 27 RCS: 4.3.57.4
/usr/sys/BINARY/syscall_trap.o subset OSFHWBIN350
CHECKSUM: 45026 9 RCSfile: syscall_trap.c RCS: 1.1.50.2
/usr/sys/BINARY/task.o subset OSFBIN350
CHECKSUM: 51912 64 RCSfile: task.c RCS: 4.3.76.2
/usr/sys/BINARY/thread.o subset OSFBIN350
CHECKSUM: 54805 27 RCSfile: thread.c RCS: 4.4.89.3
/usr/sys/BINARY/tlsb_iop.o subset OSFHWBIN350
CHECKSUM: 32182 18 RCS: 1.1.22.2
/usr/sys/BINARY/trap.o subset OSFHWBIN350
CHECKSUM: 45720 68 RCSfile: trap.c RCS: 1.2.63.3
/usr/sys/BINARY/tty.o subset OSFBIN350
CHECKSUM: 29640 34 RCSfile: tty.c RCS: 4.4.43.3
/usr/sys/BINARY/tty_pty.o subset OSFBIN350
CHECKSUM: 10848 18 RCSfile: tty_pty.c RCS: 4.6.66.3
/usr/sys/BINARY/u_mape_anon.o subset OSFBIN350
CHECKSUM: 49945 46 RCSfile: u_mape_anon.c RCS: 1.1.97.7
/usr/sys/BINARY/u_mape_dev.o subset OSFBIN350
CHECKSUM: 27398 11 RCSfile: u_mape_dev.c RCS: 1.1.22.3
/usr/sys/BINARY/u_mape_shm.o subset OSFBIN350
CHECKSUM: 46158 7 RCSfile: u_mape_shm.c RCS: 1.1.40.4
/usr/sys/BINARY/u_mape_vp.o subset OSFBIN350
CHECKSUM: 58184 16 RCSfile: u_mape_vp.c RCS: 1.1.43.2
/usr/sys/BINARY/ufs_inode.o subset OSFBIN350
CHECKSUM: 47518 86 RCSfile: ufs_inode.c RCS: 4.3.75.2
/usr/sys/BINARY/vfs_bio.o subset OSFBIN350
CHECKSUM: 50553 74 RCSfile: vfs_bio.c RCS: 4.3.51.2
/usr/sys/BINARY/vfs_ubc.o subset OSFBIN350
CHECKSUM: 09729 54 RCSfile: vfs_ubc.c RCS: 1.1.118.3
/usr/sys/BINARY/vfs_subr.o subset OSFBIN350
CHECKSUM: 26872 81 RCSfile: vfs_subr.c RCS: 4.3.110.3
/usr/sys/BINARY/vm_anon.o subset OSFBIN350
CHECKSUM: 25486 73 RCSfile: vm_anon.c RCS: 1.1.36.2
/usr/sys/BINARY/vm_anonpage.o subset OSFBIN350
CHECKSUM: 45340 6 RCS: 1.1.13.2
/usr/sys/BINARY/vm_cfg.o subset OSFBIN350
CHECKSUM: 42459 7 RCSfile: vm_cfg.c RCS: 1.1.21.3
/usr/sys/BINARY/vm_kern.o subset OSFBIN350
CHECKSUM: 30663 8 RCSfile: vm_kern.c RCS: 4.2.55.2
/usr/sys/BINARY/vm_map.o subset OSFBIN350
CHECKSUM: 20856 17 RCS: 4.4.36.2
/usr/sys/BINARY/vm_pagelru.o subset OSFBIN350
CHECKSUM: 12227 77 RCSfile: vm_pagelru.c RCS: 1.1.63.2
/usr/sys/BINARY/vm_resident.o subset OSFBIN350
CHECKSUM: 27689 73 RCSfile: vm_resident.c RCS: 4.3.47.3
/usr/sys/BINARY/vm_swap.o subset OSFBIN350
CHECKSUM: 21470 22 RCS: 1.1.60.2
/usr/sys/BINARY/vm_umap.o subset OSFBIN350
CHECKSUM: 46184 26 RCSfile: vm_umap.c RCS: 1.1.73.6
/usr/sys/BINARY/vpage.o subset OSFBIN350
CHECKSUM: 48109 7 RCSfile: vpage.c RCS: 1.1.17.2
/usr/sys/BINARY/xpt.o subset OSFHWBIN350
CHECKSUM: 30477 135 RCSfile: xpt.c RCS: 1.1.54.2
/usr/sys/BINARY/xcr_logger.o subset OSFHWBIN350
CHECKSUM: 56686 10 RCSfile: xcr_logger.c RCS: 1.1.4.4
/usr/sys/BINARY/xcr_port.o subset OSFHWBIN350
CHECKSUM: 34235 37 RCSfile: xcr_port.c RCS: 1.1.33.4
/usr/sys/arch/alpha/hal/cpuconf.c subset OSFHWBINCOM350
CHECKSUM: 29113 34
/usr/sys/conf/alpha/files subset OSFBINCOM350
CHECKSUM: 22918 27
/usr/sys/conf/alpha/.mrg..files subset OSFBINCOM350
CHECKSUM: 32160 3
/usr/sys/data/cam_data.c subset OSFBINCOM350
CHECKSUM: 11365 128 RCSfile: cam_data.c RCS: 1.1.97.3
/usr/sys/data/if_faa_data.c subset OSFBINCOM350
CHECKSUM: 64587 2 RCSfile: if_faa_data.c RCS: 1.1.11.2
/usr/sys/data/if_fxx_data.c subset OSFBINCOM350
CHECKSUM: 33123 20 RCSfile: if_fxx_data.c RCS: 1.1.17.2
/usr/sys/include/arch/alpha/cpu.h subset OSFBINCOM350
CHECKSUM: 12199 8
/usr/sys/include/arch/alpha/hal/cpuconf.h subset OSFBINCOM350
CHECKSUM: 17543 14 RCS: 9.6
/usr/sys/include/arch/alpha/pmap.h subset OSFBINCOM350
CHECKSUM: 34990 16
/usr/sys/include/dec/binlog/errlog.h subset OSFBINCOM350
CHECKSUM: 47236 204 RCSfile: errlog.h RCS: 1.1.87.3
/usr/sys/include/io/cam/cam_disk.h subset OSFBINCOM350
CHECKSUM: 20711 15 RCSfile: cam_disk.h RCS: 1.1.78.3
/usr/sys/include/io/common/devio.h subset OSFBINCOM350
CHECKSUM: 59868 29 RCSfile: devio.h RCS: 1.1.35.2
/usr/sys/include/io/dec/eisa/re.h subset OSFBINCOM350
CHECKSUM: 59532 13 RCSfile: re.h RCS: 1.1.17.2
/usr/sys/include/io/dec/netif/if_pdqreg.h subset OSFHWBINCOM350
CHECKSUM: 20392 73 RCSfile: if_pdqreg.h RCS: 1.1.32.2
/usr/sys/include/kern/ipc_tt.h subset OSFBINCOM350
CHECKSUM: 49527 3 RCSfile: ipc_tt.h RCS: 4.2.11.2
/usr/sys/include/procfs/procfs_l.h subset OSFBINCOM350
CHECKSUM: 14299 6 RCSfile: procfs_l.h RCS: 1.1.42.2
/usr/sys/include/streams/str_stream.h subset OSFBINCOM350
CHECKSUM: 60848 19 RCSfile: str_stream.h RCS: 4.2.40.3
/usr/sys/include/sys/malloc.h subset OSFBINCOM350
CHECKSUM: 01054 16 RCS: 1.1.30.2
/usr/sys/include/sys/proc.h subset OSFBINCOM350
CHECKSUM: 58812 29 RCSfile: proc.h RCS: 4.3.65.2
/usr/sys/include/sys/siginfo.h subset OSFBINCOM350
CHECKSUM: 50592 12 RCSfile: siginfo.h RCS: 1.1.35.2
/usr/sys/include/sys/signal.h subset OSFBINCOM350
CHECKSUM: 30207 21 RCSfile: signal.h RCS: 4.3.55.2
/usr/sys/include/sys/time.h subset OSFBINCOM350
CHECKSUM: 28997 8 RCSfile: time.h RCS: 4.4.23.3
/usr/sys/include/vm/vm_anon.h subset OSFBINCOM350
CHECKSUM: 38212 13 RCSfile: vm_anon.h RCS: 1.1.31.3
/usr/sys/include/vm/vm_page.h subset OSFBINCOM350
CHECKSUM: 24648 10 RCS: 4.2.18.2
/usr/sys/include/vm/vm_object.h subset OSFBINCOM350
CHECKSUM: 27465 14 RCS: 4.2.35.3
/usr/sys/include/vm/vpage.h subset OSFBINCOM350
CHECKSUM: 38661 4 RCSfile: vpage.h RCS: 1.1.11.2
/usr/sys/include/kern/thread.h subset OSFBINCOM350
CHECKSUM: 05297 12 RCSfile: thread.h RCS: 4.3.32.2
/usr/sys/include/io/dec/eisa/xcr_port.h subset OSFBINCOM350
CHECKSUM: 03812 14 RCSfile: xcr_port.h RCS: 1.1.21.2
/usr/sys/kern/lockinfo.c subset OSFBINCOM350
CHECKSUM: 12030 34 RCSfile: lockinfo.c RCS: 1.1.197.5
/usr/sys/procfs/procfs_subrs_stubs.c subset OSFBINCOM350
CHECKSUM: 31818 4 RCSfile: procfs_subrs_stubs.c RCS: 1.1.13.2
/usr/sys/vfs/vfs_conf.c subset OSFBINCOM350
CHECKSUM: 33159 10 RCSfile: vfs_conf.c RCS: 4.2.49.2
===============================================================================
Adds a mechanism to the poll() system call to allow it to be used as a timer.
PROBLEM: (TKTRA1784, QAR 49164) (Patch ID: OSF350-397)
********
This patch adds a mechanism to the poll() system call to allow it
to be used as a timer by passing in a null argument for the number
of file descriptors.
Currently the poll() system call will return immediately when passed
a null argument for the number of file descriptors.
FILE(s):
/usr/sys/BINARY/sys_generic.o subset OSFBIN350
CHECKSUM: 35610 17 RCSfile: sys_generic.c RCS: 4.4.64.2
===============================================================================
SUPERSEDES PATCH: OSF350-047 (47.00), OSF350-303 (341.00),
OSF350-333 (369.00)
This patch corrects the following:
- Fixes a problem with the tar "tv" command in reporting ownership on a file
that had no legitimate owner at the time it was archived. Based on the
position of the file in the archive, tar returned the owner of a previous
file, or the values -973 for userid and -993 for groupid.
- Fixes pax's tar and cpio archive handling to allow filesizes greater than 4GB.
- When pax command was requested to append to an existing archive, using a file
list taken from standard input, pax exited with success, although no append
was done.
- Disallow pax "b" < 512 to avoid creating corrupt files.
- The tar(pax) command doesn't correctly handle sparse files, especially Oracle
database files. Pre-allocated space is not replaced on restore.
PROBLEM: (QAR 37865) (Patch ID: OSF350-047)
********
When the pax command is requested to append to an existing archive,
using a file list taken from standard input, pax exited with success,
although no append was done.
PROBLEM: (QAR 37865) (Patch ID: OSF350-047)
********
The pax program enabled a user to create a pax archive with
an illegal blocksize ('b' option), causing the records to be seen
as corruption and the archive to be unrestoreable.
Note: The pax program 'b' option specifies an argument that is interpreted as
number of bytes (as documented). The man page fails to document that the
value can be followed by 'b' (512 byte blocks), 'k' (1024 bytes) or
'm' (1024x1024 bytes), and that the minimum is 512.
PROBLEM: (MGO101962 QAR 43077) (Patch ID: OSF350-303)
********
If a database file has been created with pre-allocated but unused disk space,
the copy operation of tar does not preserve this pre-allocated space and the
restore (tar xv) operation will therefore create a file that is of the size of
the actual used blocks.
PROBLEM: (MANBBP075 HPXQC1120) (Patch ID: OSF350-333)
********
The pax program (invoked as pax, tar or cpio) would incorrectly handle
files larger than 4GB in size. The program would not complain on creation
of an archive, however it had truncated the filesize when writing it to
the archive file header. Thus on extract, it would appear to have found
a corrupt archive. In addition it will now warn when it truncates a file
that is too large to be archived (8 GB).
PROBLEM: (SQO100400) (Patch ID: OSF350-400)
********
This patch fixes a problem with the tar "tv" command in reporting ownership
on a file that had no legitimate owner at the time it was archived.
Based on the position of the file in the archive, tar returned the owner
of a previous file, or the values -973 for userid and -993 for groupid.
FILE(s):
/usr/bin/pax subset OSFBASE350
CHECKSUM: 40898 120 RCSfile: pax.c RCS: 1.1.20.2
/usr/bin/cpio subset OSFBASE350
CHECKSUM: 40898 120
/usr/bin/tar subset OSFBASE350
CHECKSUM: 40898 120
/sbin/pax subset OSFBASE350
CHECKSUM: 32759 408 RCSfile: pax.c RCS: 1.1.20.2
/sbin/cpio subset OSFBASE350
CHECKSUM: 32759 408
/sbin/tar subset OSFBASE350
CHECKSUM: 32759 408
===============================================================================
SUPERSEDES PATCHES: OSF350-013 (13.00), OSF350-065 (65.00),
OSF350-243 (243.00), OSF350-244 (244.00)
This patch corrects the following:
- Fixes a problem that occurs on SMP systems using LSM in which
the system panics with a "simple lock time limit exceeded" message.
- This patch is required for large LSM configurations containing more than 256
plexes or more than 256 volumes.
- 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.
- 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.
- Fixes several problems that occur during certain LSM operations involving
disklabel changes.
- 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
PROBLEM: (Patch ID: OSF350-013) (QAR 36977)
********
This patch is required for large LSM configurations containing more
than 256 plexes or more than 256 volumes.
Failure to install the new volume daemon will result in the following
error message:
lsm:vold: Error: Disk group dg1, Disk rz11: Cannot auto-import group:
Too many volumes
LSM: Vold is not enabled for transactions
No volumes started
PROBLEM: (Patch ID: OSF350-065) (Case ID: HPXQ943DC)
********
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: (Patch ID: OSF350-065) (Case ID: QAR 36808)
********
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: OSF350-243)
********
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: OSF350-243)
********
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: OSF350-243)
********
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: OSF350-244)
********
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 53134, MCPM40H5M) (Patch ID: OSF350-404)
********
This patch fixes a problem that occurs on SMP systems using LSM in which
the system panics with a "simple lock time limit exceeded" message.
The problem is that the running process goes to sleep waiting for an
LSM simple lock that never becomes available.
A sample stack trace is as follows:
> 0 stop_secondary_cpu(do_lwc = 0x0)
1 panic(s = 0xfffffc00005a1568 = "event_timeout: panic request")
2 event_timeout ()
3 xcpu_puts()
4 printf()
5 panic(s = 0xfffffc0000572ea8 = "simple_lock: time limit exceeded")
6 simple_lock_fault()
7 simple_lock_time_violation()
8 voliodone()
9 biodone()
10 cdisk_complete()
11 xpt_callback_thread()
The thread holding the lock:
> 0 thread_block()
1 u_anon_faultpage()
2 u_anon_fault()
3 u_map_fault()
4 vm_fault()
5 trap()
6 _XentMM()
7 bcopy()
8 vols_volinfo()
9 volsioctl_real()
10 spec_ioctl()
11 vn_ioctl()
12 ioctl_base()
13 ioctl()
14 syscall()
15 _Xsyscall()
FILE(s):
/sbin/vold subset OSFLSMBASE350
CHECKSUM: 12475 584
/sbin/voldisk subset OSFLSMBASE350
CHECKSUM: 33680 328
/usr/sys/BINARY/dki_osf.o subset OSFLSMBIN350
CHECKSUM: 22045 9 RCS: 1.1.9.2
/usr/sys/BINARY/plex.o subset OSFLSMBIN350
CHECKSUM: 33148 12 RCS: 1.1.13.2
/usr/sys/BINARY/vol.o subset OSFLSMBIN350
CHECKSUM: 26694 128 RCS: 1.1.31.2
/usr/sys/BINARY/volted.o subset OSFLSMBIN350
CHECKSUM: 21409 6 RCS: 1.1.13.2
/usr/sys/BINARY/volspec.o subset OSFLSMBIN350
CHECKSUM: 28823 59 RCSfile: volspec.c RCS: 1.1.18.3
/usr/sys/BINARY/volblog.o subset OSFLSMBIN350
CHECKSUM: 08633 15 RCS: 1.1.13.2
/usr/sys/BINARY/volioctl.o subset OSFLSMBIN350
CHECKSUM: 53922 24 RCS: 1.1.19.2
/usr/sys/BINARY/volklog.o subset OSFLSMBIN350
CHECKSUM: 59402 17 RCS: 1.1.11.2
/usr/sys/BINARY/vol_cfg.o subset OSFLSMBIN350
CHECKSUM: 52953 2 RCS: 1.1.9.2
/usr/sys/BINARY/volroot.o subset OSFLSMBIN350
CHECKSUM: 53578 17 RCS: 1.1.17.2
/usr/sys/BINARY/volSpace.o subset OSFLSMBIN350
CHECKSUM: 52001 8 RCS: 1.1.10.2
/usr/sys/include/vxvm/vol.h subset OSFLSMBINCOM350
CHECKSUM: 14743 41 RCS: 1.1.19.2
===============================================================================
SUPERSEDES PATCHES: OSF350-363 (381.00)
This patch corrects the following:
- Fixes a problem in which a system with an HSZ70 controller with
a Q-Logic adapter or a KZPSA adapter may experience kernel memory faults
during a failover and display a message similar to the following:
panic (cpu 8): kernel memory fault
cam_logger: CAM_ERROR entry too large to log!
- A custom SCSI driver may return the error ENOMEM from its
ccmn_open_unit() routine.
PROBLEM: (HPXQ10U29) (Patch ID: OSF350-363)
********
A custom SCSI driver may encounter the unexpected error ENOMEM returned
from the ccmn_open_unit() function in the driver's slave() routine.
PROBLEM: (QAR 49907 QAR 48597) (Patch ID: OSF350-407)
********
This patch fixes a problem in which a system with an HSZ70 controller
with a Q-Logic adapter or a KZPSA adapter may experience kernel
memory faults during a failover.
A message similar to the following is displayed:
panic (cpu 8): kernel memory fault
cam_logger: CAM_ERROR entry too large to log!
FILE(s):
/usr/sys/BINARY/pdrv_common.o subset OSFHWBIN350
CHECKSUM: 45388 175 RCSfile: pdrv_common.c RCS: 1.1.93.4
===============================================================================
Fixes a problem that causes an AdvFS file system encapsulated under LSM
to appear as a user type of "gen", rather than the correct type, "fsgen".
PROBLEM: (QAR 53471, QAR 31350) (Patch ID: OSF350-410)
********
This patch fixes a problem that causes an AdvFS file system encapsulated
under LSM to appear as a user type of "gen", rather than the correct type,
"fsgen". The command voladvdomencap was patched to run volassist with a flag
-U fsgen, rather than -U gen.
FILE(s):
/usr/sbin/voladvdomencap subset OSFLSMBASE350
CHECKSUM: 31290 5 RCSfile: voladvdomencap.sh RCS: 1.1.11.2
===============================================================================
SUPERSEDES PATCHES: OSF350-150 (150.00), OSF350-209 (209.00)
This patch corrects the following:
- Fixes a wide variety of system panics and other problems caused
by random memory corruption. Problem noticed at sites hosting
a lot of streams activity.
- Successive reads wait for VTIME to expire regardless of VMIN setting.
- Fixes pause or stall conditions of up to 30 seconds when an application calls
the ldtty_close function in a STREAMS based implementation. After the pause
or stall, the application resumes normal behavior with no other apparent side
affects.
PROBLEM: (HPXQ968A7) (Patch ID: OSF350-150)
********
Successive reads wait for VTIME to expire regardless of VMIN setting
PROBLEM: (HPXQ514E3, QAR 46310) (Patch ID: OSF350-209)
********
This patch fixes pause or stall conditions of up to 30 seconds when an
application calls the ldtty_close function in a STREAMS based implementation.
After the pause or stall, the application resumes normal behavior with no
other apparent side affects.
This problem typically shows when an application outputs to a streams based
device. For example, an application "prints" data to a printer on a terminal
server using LAT protocol. The application may expect an immediate return
but instead, experiences a pause or stall for up to 30 seconds. Obtaining a
stack trace when the stall or pause condition is occuring will show
the following footprint:
0 thread_block()
1 mpsleep
2 streams_mpsleep
3 ldtty_close
4 close_wrapper
5 csq_protect
.....
.....
After the 30 seconds expires, the application returns to normal behavior with
no other side affects noticed. The stall condition in this example happened
with files in the size range of 4097 - 4960 bytes being queued to a printer
on a terminal server. The size of the files by coincidence, hit the 30 sec
sleep timer just at the right time in order to uncover the bug.
There are no error messages during the pause or stall. You must examine
the stack in order to determine if this patch applies to your condition.
PROBLEM: (HPAQ41AAX STLQ23067 UVO105389 HPAQ116QT HPAQ50RP5 HPAQ400K4
******** ZPOBA0391 ZPOB60233) (Patch ID:OSF350-411)
This is a mandatory patch for all systems.
This patch fixes a wide variety of system panics and other problems
caused by random memory corruption. The problem has typically shown up
at universities, or Internet service providers hosting a lot of streams
activity.
The following symptoms have appeared in a variety of places throughout
the kernel. Corrupted memory buckets are usually the 256-byte size, although
they could be any other size.
o Lock timeouts
o Kernel memory faults
o Unaligned kernel accesses
A typical stack trace is shown in the following example:
3 panic("pmap_activate lock timeout")
4 pmap_activate() [/src/kernel/arch/alpha/pmap.c":2710]
5 thread_run() [src/kernel/kern/sched_prim.c":2295]
6 idle_thread() [src/kernel/kern/sched_prim.c":3105]
In the stack trace above, the lock timed out because the lock structure
(at 0xfffffc0067fefe00) appeared to be locked when it really was not.
This was due to corruption of the structure by user data that had overflowed
from an mblk structure preceding this memory block.
To identify whether you have this memory corruption problem you have to
look beyond the stack trace. The stack traces will vary considerably,
even on the same system, so the only way to identify this problem is to
find the corrupted memory bucket and look at the contents.
This is a typical 512-byte corrupted memory bucket. The first 17 bytes of
data have been overwritten by data that belongs to another thread. The
17 bytes have overflowed from an mblk structure preceding this memory bucket,
and have corrupted this memory bucket, overwriting pointers or locks or
whatever the first 3 quadwords used to contain.
(kdbx) 0xfffffc0067fefe00/32X
fffffc0067fefe00: 6918a5e6f04e78d3 cf7814aca7a32d6f
fffffc0067fefe10: 0000000000000043 0000000000000000
fffffc0067fefe20: 0000000000000000 fffffffffffffff8
fffffc0067fefe30: 0000000000000000 0000000000000001
fffffc0067fefe40: 000000000044a5cc 000000000000001a
...
If you display the block of memory immediately preceding the corrupted memory,
you may see an mblk structure there, if it is still around by the time the
crash dump takes place.
Sometimes the data that has corrupted the memory bucket is readable ASCII,
but more often it is unreadable binary data.
The number of bytes of data can be anywhere from 1 byte to several quadwords
of data.
FILE(s):
/usr/sys/BINARY/ldtty.o subset OSFBIN350
CHECKSUM: 52276 95 RCSfile: ldtty.c RCS: 1.1.42.4
===============================================================================
The audit_tool command hangs if the audit log contains pathnames
that encounter boundary conditions.
PROBLEM: (CLD HPAQ61BKA, CLD MCPM20F8X) (Patch ID: OSF350-413)
********
This patch fixes a problem in which the audit_tool command will hang
if the audit log contains pathnames that encounter boundary conditions.
An example of a boundary condition that causes the problem is a component
of the pathname ending on a 1024-byte boundary.
FILE(s):
/usr/sbin/audit_tool subset OSFBASE350
CHECKSUM: 22783 128 RCSfile: audit_tool.c RCS: 1.1.35.2
===============================================================================
SUPERSEDES PATCHES: OSF350-056 (56.00)
This patch corrects the following:
- awk consumes memory until the machine swaps itself and core dumps with:
write failed, file system is full Memory fault - core dumped
- awk (nawk) doesn't always clear the previous value of the last field.
PROBLEM 1: (Case ID: HPAQ282B7) (Patch ID: OSF350-056)
**********
The awk utility will sometimes produce output that indicates that field values
are not being cleared between record reads. Specifically, the value
of the last field in a record gets left in when a new record is read in
which has a null last field.
To reproduce the problem, put the following lines into a file called,
"awktest.dat".
A~~~XYZ
~~~
x~x~x~X
1~~~
~~~
Then run the following command: awk -F~ '{print $4}' test.dat
The output should be:
XYZ
X
The output will be:
XYZ
XYZ
X
X
X
PROBLEM: (QAR 30334) (Patch ID: OSF350-418)
********
This patch fixes problem in which 'awk' will consume memory until
the machine swaps itself and core dumps with following error:
write failed, file system is full
Memory fault - core dumped
FILE(s):
/usr/bin/awk subset OSFBASE350
CHECKSUM: 16369 152 RCSfile: lib.c RCS: 1.1.15.2
/usr/bin/nawk subset OSFBASE350
CHECKSUM: 16369 152 RCSfile: lib.c RCS: 1.1.15.2
===============================================================================
SUPERSEDES PATCH: OSF350-145 (145.00), OSF350-367 (386.00)
This patch updates the FDDI driver to include:
- Fixes a problem where after a hang the system crashes with the
panic message: apecs_read_io_port. At that time, the only way
to reboot the system is to switch it OFF then ON.
- Major re-work of fta_reinitialize to fix stuck interface after halt.
- Add code to display source and destination address on bad incoming packets
(CRC, Illegal length, etc.).
- Fixed up the bumping of some DECnet counters so they could latch to their
max values.
- Upgrade/Replacement for the "FTA" FDDI driver and fixes a DMA Error
which can occur with the older driver.
PROBLEM: (7LCB21814) (Patch ID: OSF350-145)
********
Update FDDI driver to include:
- Major re-work of fta_reinitialize to fix stuck interface after halt.
- Add code to display source and destination address on bad incoming packets
(CRC, Illegal length, etc.).
- Fixed up the bumping of some DECnet counters so they could latch to their max
values.
PROBLEM: (749B23467/QAR 52293) (Patch ID: OSF350-367)
********
This patch is an upgrade/replacement for the "FTA" FDDI driver and fixes a
DMA Error which can occur with the older driver.
If it became necessary to back out a partially constructed frame from
the transmit queue, the older driver was unable to properly backed out
the frame before restarting. This resulted in the following errors being
logged to the /var/adm/messages file:
vmunix: fta0: Halted.
vmunix: fta0: Halt Reason: DMA Error
vmunix: fta0: Link Unavailable.
vmunix: fta0: Link Available.
PROBLEM: (ZUO101163) (Patch ID: OSF350-419)
********
After a hang the system crashes with the panic: apecs_read_io_port.
At that time, the only way to reboot the system is to switch it OFF then ON.
FILE(s):
/usr/sys/BINARY/if_fta.o subset OSFHWBIN350
CHECKSUM: 24181 53 RCSfile: if_fta.c RCS: 1.1.93.4
/usr/sys/data/if_fta_data.c subset OSFBINCOM350
CHECKSUM: 14908 21 RCSfile: if_fta_data.c RCS: 1.1.49.3
===============================================================================
SUPERSEDES PATCHES: OSF350X-001 (311.00)
This patch corrects the following:
- When called from an application, bookreader changes the caller's
effective UID to the real UID, but then never restores it to the
original effective UID, before returning control to the calling program.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0349U) (Patch ID: OSF350X-001)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
Note: Installation of this patch updates a static library, libbkr.a. Any
applications that are linked against the original version of the static
library will need to be relinked against the new version of the library in
order to incorporate this patch.
PROBLEM: (HPAQ214QG, QAR 44630) (Patch ID: OSF350X-037)
********
When using the Bookreader library, which is part of the DECwindows Motif
toolkit, from within an application, bookreader changes the caller's
effective UID to the real UID, but then never restores it to the
original effective UID, before returning control to the calling program.
If an application like dxchpwd is run from a non-root account, it fails
with a privilege violation.
FILE(s):
/usr/lib/libbkr.a subset OSFXDEV350
CHECKSUM: 47779 38
/usr/shlib/libDXm.so subset OSFX11350
CHECKSUM: 20327 1008
/usr/shlib/libbkr.so subset OSFX11350
CHECKSUM: 19548 40
===============================================================================
SUPERSEDES PATCHES: OSF350-124 (124.00), OSF350-177 (177.00),
OSF350-234 (234.00)
This patch corrects the following:
- A potential security vulnerability has been discovered in 'mountd', where
under certain circumstances, system integrity may be compromised. This may
be in the form of improper file or privilege management. Digital has
corrected this potential vulnerability.
- Fixed a memory leak in 'mountd' which could cause 'mountd' to run out of
virtual memory and terminate without issuing any error messages.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
- "mountd" can die without logging the event in the daemon.log file and
without generating a core file.
PROBLEM: (DEKQ60096, QAR 35852) (Patch ID: OSF350-124)
********
'mountd' had a memory leak. The 'mountd' process virtual memory usage
would continue to increase until 'mountd' was unable to obtain any more
and then it would terminate without issuing any error messages.
The memory leak occurred each time 'mountd' processed the /etc/exports file.
The larger the exports file, the more memory was lost each time it was
processed.
PROBLEM: (SSRT0379U, QAR 43739) (Patch ID: OSF350-177)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
Also add the -a option flag to request the addresses for the hostname and
verify that the name and address correspond. This is similar to the behavior
of the rshd and rlogind daemons.
PROBLEM: (HPXQ36487/QAR 45362) (Patch ID: OSF350-234)
********
'mountd' can die without logging the event in the daemon.log file and
without generating a core file. This can occur if the following
conditions are true:
o The output from the "showmount -e host" command is greater than 4K
bytes long.
o The "showmount -e host" command times out and issues the error:
Can't do Exports rpc: RPC: Timed out
The 'showmount' command has a 25 second time out, plus the typical showmount
request returns in less than a second. This problem has so far only occurred
when the NFS server is exporting a large number of file systems hosted by a
3rd party product (where a large number was greater than 100 of the 3rd party
product's entries).
Another way to cause this problem is if the 'showmount' command is aborted via
Control-C before the NFS server can return the list of exported file systems.
Other systems, such as PCs requesting a list of exported file systems, could
also cause this problem.
PROBLEM: (SSRT0496U) (Patch ID: OSF350-420)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file or privilege management. Digital has
corrected this potential vulnerability.
FILE(s):
/usr/sbin/mountd subset OSFNFS350
CHECKSUM: 39060 56 RCSfile: mountd.c RCS: 4.2.35.5
===============================================================================
SUPERSEDES PATCH: OSF350-147 (147.00), OSF350-174 (174.00),
OSF350-316 (354.00)
This patch corrects the following:
- Fixes the problem where applications running System V pseudoterminal
slave pty can hang forever on open() system call.
- The system becomes totally unresponsive every 2-5 days, not responding to
terminals, to the system console, or to pings.
- Add support for FIONREAD.
- Corrects problem where ntalk daemons are hung.
- Fixes a problem that causes the system to "assert_wait" panic with streams
code on the stack.
PROBLEM: (FNO100055,MXOQ10017,MXOB10972,MXOB20803) (Patch ID: OSF350-147)
********
The system becomes totally unresponsive every 2-5 days, not responding to
terminals, to the system console, or to pings.
It would not show any messages on the console or in any log files. The only
way to recover was to reboot the system.
Before the system hung up, vmstat showed that the wired pages list kept growing.
PROBLEM: (FNO100055,MXOQ10017,MXOB10972,MXOB20803) (Patch ID: OSF350-147)
********
There was no support for FIONREAD.
PROBLEM: (HPAQ23547) (Patch ID: OSF350-174)
********
This patch fixes a problem on a system where the ntalk daemons are hung. Once
the system gets into this state, where the ntalk daemons are hung, the user
will not be able to kill these processes and the only way to get rid of this
process level hang is to reboot the system. A typical stack trace for the hung
process will show a makealias() call in it, although, the rest of the stack
trace may have any number of different routines in it.
PROBLEM: (HPAQ95241, QAR 50022) (Patch ID: OSF350-316)
********
This patch fixes a problem that causes the system to panic with "assert_wait"
as the message with streams code on the stack. A representative stack trace is:
panic(s = "assert_wait")
assert_wait_mesg sched_prim.c
pts_close pty.c
close_wrapper str_subr.c
csq_protect str_synch.c
osr_pop_subr str_osr.c
osr_close_subr str_scalls.c
pse_close str_scalls.c
speclose spec_vnops.c
clearalias spec_vnops.c
exit kern_exit.c
psig kern_sig.c
trap trap.c
PROBLEM: (QAR 52115) (Patch ID: OSF350-422)
********
An application running System V using psuedoterminals may hang
if it opens the slave side before the master is open.
If the slave side of a System V master psuedoterminal is opened before it is
unlocked on the master side via unlockpt(), the calling process will block
forever on the open() even after the unlockpt() has been issued and the lock
flag lifted from the device. Once the out of sequence race condition occurs,
the slave device cannot be opened again by any process until the original hung
process is terminated.
FILE(s):
/usr/sys/BINARY/pty.o subset OSFBIN350
CHECKSUM: 48173 95 RCSfile: pty.c RCS: 1.1.53.5
/usr/sys/include/tty/pty.h subset OSFBINCOM350
CHECKSUM: 13128 12 RCSfile: pty.h RCS: 1.1.29.3
===============================================================================
Fixes a problem the doconfig program hangs after being invoked by
the uuxqt program.
PROBLEM: (QAR 53588) (Patch ID: OSF350-423)
********
This patch fixes a problem that causes the doconfig program to hang
when invoked by the uuxqt program. When uuxqt invokes doconfig,
doconfig spawns a child process that should be terminated by a
SIGTERM signal. Instead, the process ends up waiting on a SIGCHLD
which never occurs because the child process never acts on the SIGTERM.
FILE(s):
/usr/lib/uucp/uuxqt subset OSFUUCP350
CHECKSUM: 59637 352 RCSfile: uuxqt.c RCS: 4.3.6.3
===============================================================================
SUPERSEDES PATCHES: OSF350-255 (255.00)
This patch corrects the following:
- Fixes a problem in which the 'date' command is unable to set
the date to January 1, 1970 00:00:00 GMT or February 29, 2000.
- Enhancements to the date command for Year 2000 support.
PROBLEM: ( TKTQ22519, UVO104025, QAR 45258 ) (Patch ID: OSF350-255)
********
Identifying limitations of original date command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The date command was not able to accurately set the date past the year
1999. For example:
Display current date:
$ date
Tue Jul 16 11:01:50 EDT 1996
Attempt to set the date to 12:55 PM, January 1, 2000
$ date 0101125500
Thu Feb 7 19:24:02 EST 2036
Enhancements to the date command for Year 2000 support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The date command has been enhanced to support setting the system date
past the year 1999, providing customers with the ability to begin
testing their software for potential century rollover problems. The
changes are outlined in the following sections.
Syntax
The following formats are valid for setting the system date
using the date command.
Using the XPG4-UNIX format:
date mmddHHMM[yy]
Using one of three Digital formats:
date mmddHHMM[[cc]yy][.ss]
date [[cc]yy]mmddHHMM[.ss]
date mmddHHMM[.ss[[cc]yy]]
The following definitions apply:
mm is the month number
dd is the number of the day in the month
HH is the hour in the day
MM is the number of minutes
ss is the number of seconds
yy is the last two digits of the year
cc is the first two digits of the year
Note that the LC_TIME variable, if it is defined, controls the
ordering of the day (dd) and month (mm) numbers in these
formats. The default order is the month (mm) followed by the
day (dd).
Optional Century [cc] Input
Each of the Digital formats for the date command allow the
optional input of the century (first two digits of the year).
This century field is optional to ensure that input formats
previously accepted by the date command are still supported.
Currently, the XPG4-UNIX format mmddHHMM[yy] does not have a
century field. This is consistent with current X/Open
specifications regarding the date command. The century field
will be added to this format in a future release of Digital
UNIX once this new field is officially supported in future
revisions of X/Open's UNIX specification.
Handling of Two-Digit Year Input
When the year is specified by using two digits (as in the
XPG4-UNIX format or when the [cc] field is omitted from the
Digital formats), the century is determined in the following
manner: if the specified two-digit year is between 69 and 99
inclusive, the 20th century is assumed (that is, 19yy),
otherwise the 21st century is assumed (that is, 20yy).
The algorithm above is consistent with current drafts of
forthcoming X/Open UNIX specifications regarding two-digit
year handling in various system interfaces and commands,
including the date command. This algorithm is based on the
standard UNIX epoch (12:00:00 AM Jan 1, 1970 UTC), minus one
year to account for different time zones. Internal UNIX time
handling is based on the number of seconds since this epoch.
Handling of Ambiguous Input
If the input string is ambiguous, that is, if the format
cannot be conclusively determined from the data, the date
command will issue a warning to STDERR and assume the
mmddHHMM[[cc]yy][.ss] format. To avoid ambiguous input, use
one of the three Digital formats and specify the [cc] field.
Examples
To set the date to 09:34:00 AM Jan 7, 2000:
Using the mmddHHMM[yy] XPG4-UNIX format:
# date 0107093400
Using the mmddHHMM[[cc]yy][.ss] Digital format:
# date 010709342000
# date 0107093400.00
# date 010709342000.00
Using the [[cc]yy]mmddHHMM[.ss] Digital format:
# date 0001070934
# date 200001070934
# date 200001070934.00
Using the mmddHHMM[.ss[[cc]yy]] Digital format:
# date 01070934.0000
# date 01070934.002000
An example of ambiguous input:
# date 0101010000
This input could be recognized as one of the following
formats:
mmddHHMM[[cc]yy][.ss] meaning 01:00:00 AM Jan 1, 2000
[[cc]yy]mmddHHMM[.ss] meaning 12:00:00 AM Jan 1, 2001
In this case, the date command will display a warning and
assume the mmddHHMM[[cc]yy][.ss] format, setting the date to
01:00:00 AM Jan 1, 2000.
PROBLEM: (QAR 50276, QAR 53348) (Patch ID: OSF350-431)
********
This patch fixes a problem in which the 'date' command is unable to
set the date to January 1, 1970 00:00:00 GMT or February 29, 2000.
To reproduce the problem, do the following:
root# TZ=:GMT ; export TZ
root# date 01010000.0070
FILE(s):
/sbin/date subset OSFBASE350
CHECKSUM: 44372 288 RCSfile: date.c RCS: 4.2.33.3
/usr/bin/date subset OSFBASE350
CHECKSUM: 00682 24 RCSfile: date.c RCS: 4.2.33.3
/usr/lib/nls/msg/en_US.ISO8859-1/date.cat subset OSFBASE350
CHECKSUM: 30685 1
===============================================================================
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: OSF350-432)
********
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 OSFHWBIN350
CHECKSUM: 37070 17 RCSfile: apecs.c RCS: 1.1.49.2
/usr/sys/BINARY/lca.o subset OSFHWBIN375
CHECKSUM: 46818 21 RCSfile: lca.c RCS: 1.1.52.2
===============================================================================
Fixes a problem where the AdvFS filesystem command "vquotacheck -a"
erroneously sets all quotas for users to values derived from the
last AdvFS fileset in /etc/fstab, rather than the correct values
for each individual fileset.
PROBLEM: (HPXQB22D0, QAR 45498) (Patch ID: OSF350-437)
********
This patch fixes problems with the AdvFS filesystem command "vquotacheck -a".
This command erroneously set all quotas for users to values derived
from the last AdvFS fileset in /etc/fstab, rather than the correct values
for each individual fileset.
FILE(s):
/usr/sbin/vquotacheck subset OSFADVFS350
CHECKSUM: 63767 536 RCSfile: vquotacheck.c RCS: 1.1.6.4
===============================================================================
SUPERSEDES PATCHES: OF350-086 (86.00), OSF350-120 (120.00),
OSF350-168 (168.00), OSF350-246 (246.00),
OSF350-276 (276.00), OSF350-337 (373.00)
This patch corrects the following:
- Fixes the following linker problems:
o Hidden/export symbol wildcard problem
o Assert getting generated with R_GPVALUE relocations
o improper Text segment alignment processing
o internal memory managment problem processing c++ program
- A problem where use of "ld -r" will change symbol preemption behavior.
- Numerous previous ld corrections.
PROBLEM: (Patch ID: OSF350-086) (CLD MGO101594/Qar 37210)
********
Putting a cobol object file in a shared library, and linking an exe aginst that
lib results in unexpected behaviour at run-time.
It will now be allowable to have _cobol_main in shared libs as well as the
call shared executable.
PROBLEM: (Patch ID: OSF350-086) (QAR 29936 )
********
Internal check for object file consistency with a .dynrel and .text interaction
triggered a confusing assertion.
The ld assertion has been replaced by a more understandable error msg.
PROBLEM: (Patch ID: OSF350-086) (QAR 28274)
********
Eliminated warnings about non-quickstart due to shared library mismatches.
This warning was deemed too confusing to be emitted by default (especially
since it is emitted for links of all Fortran, C++, Ada, and Pascal programs).
PROBLEM: (Patch ID: OSF350-086) (CLD UVO103186/QAR 34454)
********
ld crashes with too many GOT entries. The problem occured when there was
exactly 8190 symbols going into a GOT. If you have 8189 symbols--it will work.
If you had 8191 symbols trying to be referenced through the GOT--it will also
work.
PROBLEM: (Patch ID: OSF350-086) (CLD HPXQ75BA6/QAR 35309)
********
ld would core dump when an object file had a bad auxiliary table.
An assertion was added to ld so it will catch these files.
PROBLEM: (Patch ID: OSF350-086) (QAR 33840)
********
ld would core dump - an internal switch case entry was missing a break for
some basic type processing.
Missing break statement added.
PROBLEM: (Patch ID: OSF350-086) (QAR 28322)
********
ld would core dump when linking a large application.
The hash table scheme for internal file processing had a problem when it hashed
more than 32K files to the same bucket.
PROBLEM: (Patch ID: OSF350-086) (QAR 29272)
********
ld did not handle the case of an archive with no archive header. ld now issues
a warning.
PROBLEM: (Patch ID: OSF350-086) (QAR 37709)
********
linked program would core dump when profiling.
ld was incorrectly marking routines.
PROBLEM: (Patch ID: OSF350-086) (QAR 30551)
********
Put checks in to not core dump with bad objects.
PROBLEM: (Patch ID: OSF350-086) (QAR 33413)
********
When ld parses -static it didn't do enough error checking to insure its
meaningful to have -static. A user used -static when they meant -non_shared
PROBLEM: (Patch ID: OSF350-086) (QAR 28452)
********
The strip utility would strip an object with relocations without diagnosing
that fact. This was due to ld -r setting F_EXEC under certain conditions.
PROBLEM: (Patch ID: OSF350-086) (QAR 29519)
********
ld core dumping.
This internal logic problem was due to a special case with an external symbol
not getting matched up with object file (pmext with a pobj). Special case
logic was added.
PROBLEM: (Patch ID: OSF350-086) (QAR 36744)
********
ld was in an infinte loop due to a bad object file. Logic was added
to Avoid getting stuck in a loop if stBlock symbols are invalid in
the local symbol table.
PROBLEM: (Patch ID: OSF350-086) (QAR 37849)
********
ld was changed to allow cross mode to read compressed objects.
PROBLEM: (Patch ID: OSF350-086) (QAR 30052)
********
ld outputs erroneous warning messages about exception info when linking modules
with no text region.
PROBLEM: (Patch ID: OSF350-086) (QAR 37062)
********
ld generated an assertion in get_ext_map().
This problem appears to be the result of other problems occuring in the linker
prior to the compact relocation code. The linker is generating a relocatable
image (preserving and updating relocation records), yet it has not set
"relocatable=1" internally. Thus, we attempt to generate compact relocation
and also preserve regular relocations. This causes the problem in the compact
code.
The solution was not to adjust relocation record that are relative to undefined
symbols unless we are creating a relocatable image. The compactcode expect
unadjusted relocation records
PROBLEM: (Patch ID: OSF350-086) (QAR 30295)
********
Internal ld problem in not properly handling multiple GPRELLOW relocations
for a single GPHIGH.
PROBLEM: (Patch ID: OSF350-086) (CLD MGO101520/ QAR 37272)
********
ld should call msync before exiting.
Add msync system call in close_output() and have it called only when mmap'ing
(ie, fix cross mode linker). This is to avoid having the data sit around in the
ubc for an indefinite period of time.
PROBLEM: (Patch ID: OSF350-086) (QAR 35624)
********
ld isnt checking return code from close().
Add code to check the return code from close(), since we cannot detect physical
device write failures when doing mmap'd output, we ought to allow for the fact
close() may return an error code.
PROBLEM: (Patch ID: OSF350-086) (QAR 21873 CL)
********
`ld -m` does not print the map for all sections.
Improved ld's output of its section mapping.
PROBLEM: (Patch ID: OSF350-086) (QAR 26939)
********
The _edata program location is being set incorrectly.
The _edata program location, documented in the end(3) man page, was being set
incorrectly in an executable built non-shared. It's address should be greater
than or equal to the address of _fdata and less than or equal to the address
of _fbss.
PROBLEM: (Patch ID: OSF350-086) (QAR 27810)
********
ld -hidden fails to hide symbol problem was corrected.
PROBLEM: (Patch ID: OSF350-086) (QAR 29264)
********
No method to select stat libs when stat and shared libs installed on same dir.
This was added for MicroFocus Cobol. The new ld options "-no_so" and
"-so_archive" have been added to ld. The -Bstatic and -Bdynamic options
described in the problem statement can be mapped respectively to -no_so and
-so_archive.
PROBLEM: (Patch ID: OSF350-086) (QAR 30520)
********
"-taso -shared" can core dump linker.
The problem is in relocate.c in the processing of R_REFLONG. In the -taso code
it dereferences an uninitialized 'pmext'when the relocation is local.
PROBLEM: (Patch ID: OSF350-086) (QAR 31941)
********
ld causes an initialization order problem for DEC C++ programs linked
-non_shared. Unlike with -call_shared programs, ld calls __init... routines in
the order that they are found on the ld command line.
DEC C++ constructs static objects by generating __init routines. The generated
__init routines in the user's code can legally reference static objects [which
have __init routines] in the C++ class library (libcxx.a). Unfortunately,
since user's .o files appear on the command line before libcxx.a, the user's
__init routines are invoked before the class library __init routines. Thus
the user's __init routine will reference the class library before the latter ha
been initialized.
To get around this problem, DEC C++ declares a static object in each class
library header file. The static object's constructor calls a routine that
initializes the class library. Unfortunately, doing this requires that a call
to the initialization routine be made by every module that includes the header
file. For large programs, this can result in thousands of unnecessary calls an
significant performance degradation at image startup.
PROBLEM: (Patch ID: OSF350-086) (QAR 32610)
********
(ld) shared library -init option problem.
Core dump occurred for external init routine when linking with -no_excpt.
Since the symbols being called are not defined in the executable, ld satisfies
the references in the init driver using stubs. A stub is a small code sequence
that loads a symbol index and calls the loader to resolve it. The stub *is*
local to the executable, which means that the pc-relative jump can be made
without a problem.
The init and fini drivers are invoked with the loader's GP as its initial GP
value. As inits and finis are called, they load their own GP value. Stubs,
on the other hand, need to have a valid GP value from which to load a GOT(0)
value, this is the address of the loader's lazy_text_resolve() routine.
Any valid GP will do, except for the loader's. After the first init routine
has been called, the GP value will be valid.
In this problem test case, the first init called is a stub'ed routine. Normally,
the exception handling init routines are first, but the -no_excpt linker
switch causes them not to be linked in.
This problem has been fixed by establishing an initial GP value for the init
and fini driver routines.
PROBLEM: (Patch ID: OSF350-086) (QAR 32881)
********
Decc++ needs to allow to build modules from last linked to 1st linked.
The customer requests this option so that software which they have developed
on a Sun which initializes in reverse module order can be efficiently ported
to Alpha/OSF.
To force init routines to run in reverse link order an option has been added -
you can now use the "-reverse_init_order" linker option.
PROBLEM: (Patch ID: OSF350-086) (QAR 33972)
********
Linker produces shared libraries with a bad gp_value entry.
The linker can be made to produce shared libraries with a bad (NULL) entry for
gp_value. Whether or not this occurs depends on the order of the link options.
This doesn't seem to effect the operation of the libraries, but it causes ATOM
to fail.
PROBLEM: (Patch ID: OSF350-086) (QAR 34742)
********
Bad ld optimization at -o2 for alternate entries.
The problem is that linking -O2 will remove the load of $27 incorrectly when
the destination is to an alternate entry point with the same address as the
main entry point.
PROBLEM: (Patch ID: OSF350-086) (QAR 34923)
********
-X option in the linker strips away language information.
The -x option in the linker strips away language information, making debugging
problematic even with the symbols that remain. There can be considerable
debugging done with -x level information, provided the language is available.
PROBLEM: (Patch ID: OSF350-086) (QAR 35460)
********
ld does not relocate values of symbols whose symbol type and symbol class
are (stSplit,scText).
PROBLEM: (Patch ID: OSF350-086) (CLD USG-02631/QAR 35475)
********
linker gives 'Internal error in /bin/ld: bad index in get_extmap()'.
PROBLEM: (Patch ID: OSF350-086) (QAR 36631)
********
ld problem with _edata if linking f77 produced .o file.
The _edata program location, documented in the end(3) man page, was being set
incorrectly in an executable built non-shared. It's address should be greater
than or equal to the address of _fdata and less than or equal to the address
of _fbss.
PROBLEM: (Patch ID: OSF350-086) (QAR 36793)
********
A shared library built with -check_registry so_locations may dump core accessing
.rdata symbols. If the shared library grows too big for it's text to fit in
the slot allocated for it in an so_locations file, ld will move the text of the
library to the next available text slot. It then corrects all the text symbol
addresses by adding the difference of the reserved text slot and the newly
allocated text slot. The difference is also added to .rdata symbols, but
.rdata symbols are in data not text, so the resulting addresses are invalid.
PROBLEM: (Patch ID: OSF350-086) (QAR 36794)
********
Strong symbol not preempted when ref'd by weak counterpart.
A simple test case will show that when a strong symbol is referenced via its
weak counterpart the reference cannot be preempted by another instance of the
strong symbol. This problem only occurs when the executable and it's shared
library dependencies are quickstarted.
PROBLEM: (Patch ID: OSF350-086) (QAR 37003)
********
Linker produces bad symtab with -x and -r or
The problem occurs when you compile an application with either -g1 or -g2 and
then link the resulting objects with -r and -x. The result is that the
procedure table's 'isym' and 'adr' fields are set incorrectly. This causes
problems with tools that consume these broken symbol tables.
PROBLEM: (Patch ID: OSF350-086) (QAR 21873)
********
`ld -m` does not print the map for all sections.
This link fails with the error message shown above and no output file is
produced. There is obviously an assumption in the implementation of the -m
option that the .rdata section always exists.
PROBLEM: (Patch ID: OSF350-086) (QAR 37279)
********
'ld -m fails' when output file has no .rdata section.
This link fails with the error message shown above and no output file is
produced. There is obviously an assumption in the implementation of the
-m option that the .rdata section always exists.
PROBLEM: (Patch ID: OSF350-086) (QAR 38021)
********
Cannot link with stripped shared libraries.
PROBLEM: (Patch ID: OSF350-086) (QAR 38040)
********
ld error -- bad isym in proc table.
The problem occurs when you compile an application with either -g1 or -g2 and
then link the resulting objects with -r and -x. The result is that the
procedure table's 'isym' and 'adr' fields are set incorrectly. This causes
problems with tools that consume these broken symbol tables.
PROBLEM: (Patch ID: OSF350-086) (QAR 38054)
********
Cannot link with stripped shared libraries
PROBLEM: (Patch ID: OSF350-086) (QAR 38063)
********
proc table incorrect for simple c++ program
PROBLEM: (Patch ID: OSF350-086) (QAR 38334)
********
can't link stripped libs
PROBLEM: (Patch ID: OSF350-120) (Case ID: UVO102899 HPXQ55AE4 qar43081)
********
When running a link involving a large number of input objects on a small memory
system, the usability of the system may be impacted by the link operation. This
patch makes available the "-nommap" switch to reduce the amount of page faults
incurred by ld. The -nommap switch may be used on the cc command line, an ld
command line or placed in /usr/ccs/lib/cmplrs/comp.config. Placing it in
comp.config, of course, causes the option to be used on all link operations
performed on a system.
PROBLEM: (QAR #44310) (Patch ID: OSF350-168)
********
A call-shared application which overloads a shared library procedure with an
additional implementation of the procedure in the main executable can
"Segmentation fault". The problem may be sensitive to link order. Linking
non-shared should cause the problem to go away. One may be able to determine
that the gp register is incorrectly set.
This problem results from the linker incorrectly determining that the gp
prologue can be "optimized away". You can not work around this problem by
linking debug.
The patched linker correctly determines when this optimization can be applied.
If an application does have this problem, you must install this patch and
re-link to correct the problem.
This problem has proven to be extremely rare.
PROBLEM: (qar 42274) (Patch ID: OSF350-246)
********
Link times increases exponentially when using ld's -hidden option.
PROBLEM: (qar 43546) (Patch ID: OSF350-246)
********
The linker is extremely slow when linking against a large number of .so
(shared library) files.
PROBLEM: (QAR 47588) (Patch ID: OSF350-276)
********
Linker executes an error exit with chmod() permission problems and certain
data-segment alignments for OMAGIC files.
PROBLEM: (QAR 48365) (Patch ID: OSF350-276)
********
Linker hangs (fails to complete execution).
PROBLEM: (49301) (Patch ID: OSF350-337)
********
This patch fixes a problem where use of "ld -r ..." will change symbol
preemption behavior. Without this patch, some global relocations can be
converted to locals as an optimization. These locals cannot be preempted.
An undocumented linker option has been added in the patched linker to prevent
this conversion. This new switch is "ld -no_local_conversion ..."
PROBLEM: (QAR 53151) (Patch ID: OSF350-443)
********
At link-time the linker issues an ASSERT statement from within the
module relocate.c. This will only be observed for very large applications
that build a final image based on previously linked 'ld -r' object files.
assertion failed: EX at ../../../../../../src/usr/ccs/bin/ld/relocate.c line 2471
PROBLEM: (QAR 55440) (Patch ID: OSF350-443)
********
Hidden/Export Symbol wildcard problem:
A regression was introduced into the linker when -hidden symbol
processing was scaled up to use a hash table. The wildcard capability
with the "exported_symbol" option was completely lost. This fix
makes wildcards functional for hidden/export symbols.
An example of wildcard usage that was no longer functional is:
ld -o libf.so -shared -all -hidden -exported_symbol 'X500*' file.o -lc
Any symbol beginning with X500 should be "GLOBAL" not "LOCAL".
To check if a symbol is global use the following odump command
on the library that is produced by the linker:
odump -Dt libf.so
Shows the symbol being GLOBAL or LOCAL
PROBLEM: (QAR 54224) (Patch ID: OSF350-443)
********
The linker was improperly rounding -T values to 64K increments even when
linking OMAGIC files, which do not have the same rounding requirements.
It turns out that the check being made in the ld.c was already being
done in layout, so all we really need to do is to remove the bogus check
in ld.c
PROBLEM: (QAR 55693) (Patch ID: OSF350-443)
********
The linker fails to link a c++ program issuing an "ld_munmap error" message.
FILE(s):
/usr/ccs/lib/cmplrs/cc/ld subset OSFBASE350
CHECKSUM: 46023 792 RCSfile: ld.c RCS: 4.3.74.7
RCSfile: uldgnum.c RCS: 1.1.13.2
RCSfile: ldgetname.c RCS: 4.3.5.2
RCSfile: ldr_atexit.c RCS: 4.2.9.2
RCSfile: ldr_dummy2.c RCS: 4.2.10.2
RCSfile: ldr_status.c RCS: 4.2.8.3
===============================================================================
SUPERSEDES PATCH: OSF350-049 (49.00), OSF350-262 (262.00)
This patch corrects the following:
- Fix enables ar to find object modules specified for deletion or extraction
whose names are longer than 13 characters.
- Failures may occur when nm or odump are run on certain compressed archive
libraries built with the ar command.
- The ar command -x option, which extracts archive files, may, in error,
return a message stating that the file was not found.
PROBLEM: (QARs 33128,36370,36883,37335) (Patch ID: OSF350-049)
********
When nm or odump are run on certain compressed archive libraries
built with the ar command, the following failures *may* occur:
(note - this does not happen with all archive libraries)
$ nm libm.a > /dev/null
Warning: Symbol table header magic is 0x4eff
Fatal: ran out of heap space
$ odump -tv libm.a > /dev/null
Warning: Symbol table header magic is 0x0
libmld: init_ldfile:non-mips symbol table 0
Assertion failed: LSYMHEADER(ldptr)->pcfd = (pCFDR)calloc(cbCFDR,LPHDR(ldptr)->
ifdMax), file ../../../../../../src/usr/ccs/lib/libmld/ldfcn.c, line 333
Resources lost(coredump)
$
Alternative if this patch is not installed:
- Do not use the objZ utility to pre-compress objects before archiving
with ar, instead use "ar rZ".
- Do not combine objects and non-object files (such as text files) in
an archive.
In the absense of this patch, each of these cases has the potential of
creating a bad archive symbol table, leading to the above problems.
PROBLEM: (DJOB3K133, QAR 46595) (Patch ID: OSF350-262)
********
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.
PROBLEM: (QAR 51801, QAR 55270) (Patch ID: OSF350-444)
********
The ar command is unable to find object modules specified for
deletion or extraction whose names are longer than 13 characters.
FILE(s):
/usr/ccs/lib/cmplrs/cc/ar subset OSFBASE350
CHECKSUM: 19006 376 RCSfile: ar.c RCS: 4.2.23.5
RCSfile: bsearch.c RCS: 4.2.6.3
/usr/ccs/lib/cmplrs/cc/libmld.a subset OSFCMPLRSEXT350
CHECKSUM: 45305 495 RCSfile: ldfcn.c RCS: 4.3.37.2
RCSfile: obj.c RCS: 4.3.40.2
/usr/ccs/lib/cmplrs/cc/nm subset OSFBASE350
CHECKSUM: 44434 312 RCSfile: nm.c RCS: 4.2.13.3
/usr/ccs/lib/cmplrs/cc/odump subset OSFBASE350
CHECKSUM: 52209 376 RCSfile: elfdump.c RCS: 4.1.12.2
===============================================================================
SUPERSEDES PATCHES: OSF350-288 (288.00)
This patch corrects the following:
- Fixes a memory leak problem using the STREAMS Data Link Bridge (dlb)
pseudodevice driver and could cause a "freeing free mbuf" panic
when system memory is exhausted.
- This patch corrects a problem with packets out of order experienced by
some PATHWORKS Netbuei clients.
PROBLEM: ( QAR 47254 CLD HPXQ77186 ) (Patch ID: OSF350-288)
********
Ordering is not currently guaranteed by the streams infrastructure which can
cause some packets to be delivered out of order. This causes a problem with
the Netbeui streams stack, which requires that streams packets be delivered
in order.
PROBLEM: (QAR 48892, 49073) (Patch ID: OSF350-445)
********
This patch fixes a memory leak problem that occurs with the STREAMS
Data Link Bridge (dlb) pseudodevice driver. This problem could
cause a "freeing free mbuf" panic when system memory is exhausted.
FILE(s):
/usr/sys/BINARY/dlb.o subset OSFBIN350
CHECKSUM: 11324 116 RCSfile: dlb.c RCS: 1.1.22.3
===============================================================================
Fixes several I/O problems in the kernel that occur on
AlphaStation 500 and AlphaStation 600 systems. The problem
causes these systems to hang or run with reduced performance.
PROBLEM: (QAR 47627) (Patch ID: OSF350-446)
********
This patch fixes several I/O problems in the kernel that occur on
AlphaStation 500 and AlphaStation 600 systems. The problem causes
these systems to hang or run with reduced performance.
This patch increases performance through data type alignment, provides
bus space to bus space data copy changes to eliminate data corruption,
and translates an I/O handle to a valid CPU address to prevent system hangs.
FILE(s):
/usr/sys/BINARY/dc21171.o subset OSFHWBIN350
CHECKSUM: 09346 20 RCSfile: dc21171.c RCS: 1.1.46.2
===============================================================================
SUPERSEDES PATCHES: OSF350-007 (7.01), OSF350-027 (27.00),
OSF350-080 (80.00), OSF350-088 (88.00),
OSF350-108 (108.00), OSF350-128 (128.00),
OSF350-133 (133.00), OSF350-137 (137.00),
OSF350-154 (154.00), OSF350-217 (217.00),
OSF350-222 (222.00), OSF350-236 (236.00),
OSF350-253 (253.00), OSF350-279 (279.00),
OSF350-003 (3.00), OSF350-210 (210.00),
OSF350-348 (394.00), OSF350-348-1 (394.01),
OSF350-046 (46.00), OSF350-349 (368.00),
OSF350-349-1 (348.00), OSF350-398 (419.00),
OSF350-412 (430.00)
This patch corrects the following:
- Fixes a problem where printing of a string with a specified precision
could result in a segmentation fault.
- Fixes a TCP/IP problem that can occur with programs linked with
the libc library. These programs may return a value of (-1)
when calling the svc_tcp() function.
- /sbin/shutdown takes too long if there are many open LAT lines.
- Occasionally, users will still be present in /var/adm/utmp even after they
have logged out.
- BIND clients cannot perform lookups when given a nameserver address that is an
interface alias address on the BIND server. The lookup hangs for a period of
time, then times out.
- A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this
potential vulnerability.
- On systems with worldwide support and message catalogs installed: when a
locale is set, xdm (the workstation login screen) and the passwd command will
core dump when displaying some messages.
- sprintf() can add one extra uninitialized character after "%*.*f" format
strings if the precision is zero.
- A dataless system will hang when transitioning from single to multi-user mode.
- Multithreaded applications run on V3.2C which use any of the get*_r()
functions may dump core or produce incorrect results.
- strncat() reads past end of source array.
- Fix multiple processes from adding duplicate ut_id lines in the utmp file with
duplicate ut-id keys.
- Corrects several errors in the syslog entry written by the su program.
- taso applications that set the malloc(3) __sbrk_override and __taso_mode
tuning parameters to true. Under these circumstances, malloc(3) can return
ENOMEM before all of the taso address space is allocated.
- A memory leak problem associated with the strxfrm() and wcsxfrm() functions
and some incorrect behavior in __do_replacement(), which is used by both
strxfrm() and strcoll().
- The filename pattern-matching behavior of the find command when it includes
the "?" metacharacter. The bug actually resides in fnmatch(), which is used
by the find command.
- In some cases, sendmail generates a core dump when it receives an illegal
command, after installing patch OSF350-128.
- After a user logs into a system with an SRV4-style LAT device: When the
ttyslot function is called, the system fails to find the device and returns
a value of zero, indicating an error in the ttyslot function.
- A heavy load on a NIS server causing more than 32 connections, ypserv would
"lose" some of them. Problem is more obvious on ypserv but can occur
on ypbind.
- NIS slaveservers will not accept a push from the master server of a new map.
- A potential security vulnerability has been discovered in BIND
(Domain Name Service), where under certain circumstances, system integrity
may be compromised. This may be in the form of improper file or
privilege management. Digital has corrected this potential vulnerability.
- Fix to allow "getty" to accept uppercase usernames.
PROBLEM: (ZPOB11462/ZUO100453, SSRT0330U) (Patch ID: OSF350-007)
********
o Occasionally, users will still be present in /var/adm/utmp even after
they have logged out. When this happens the user still appears as
logged in when displayed by "who" or "last".
o A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM: (TKTQ42106,TKTB75167,TKTB83473) (Patch ID: OSF350-027)
********
On systems with worldwide support and with message catalogs installed, when a
locale is set, xdm (the workstation login screen) and the passwd command will
core dump when displaying some messages.
For xdm, the message "Too many users logged on already. Try again later."
will cause a core dump.
For the passwd command, the message "Sorry" will cause a core dump.
The core dumps for both xdm and passwd will show the following routines
at the top of the stack:
0 strlen() ["../../../../../src/usr/ccs/lib/libc/alpha/strlen.s":54
1 _doprnt() ["../../../../../src/usr/ccs/lib/libc/doprnt.c":1259]
2 vsprintf() ["../../../../../src/usr/ccs/lib/libc/vsprintf.c":103]
3 __sia_warning() ["../../../../../src/usr/ccs/lib/libc/SIA/sia_log.c":250]
PROBLEM: (QARs - 35249,35258,35271,3527) (Patch ID: OSF350-080)
******** (CLDs - STLN62255,HPXQ56EAD,HPAQ6151D,HPXQ64859)
sprintf() can add one extra uninitialized character after "%*.*f" format strings
if the precision is zero.
One can work around this problem by initializing the sprintf() "buffer" with the
NULL (\0) character before calling sprintf().
csh> cat test.c
main()
{
double val = 1.1;
int fw = 5; /* Width of field */
int dp = 0; /* Decimal Places */
char buf[20];
strcpy(buf, "XXXXXX");
sprintf(buf, "%*.*f", fw, dp, val);
puts(buf);
}
csh>
csh> cc test.c
csh>
csh> a.out
1X
csh>
PROBLEM: (QAR 40685) (Patch ID: OSF350-088)
********
A dataless system will hang when transitioning from single to multi-user mode.
PROBLEM: (QAR 41702) (Patch ID: OSF350-108)
********
Multithreaded applications run on V3.2C which use any of the get*_r() functions
may dump core or produce incorrect results. The problem will show up only in
code that is linked against, or dlopen()'s libc_r and makes calls to functions
whose names match the pattern get*_r.
A program exhibiting this problem will often core-dump with a stack
trace which shows it was in one of the get*_r functions.
PROBLEM: (SSRT0359X) (Patch ID: OSF350-128)
********
A potential security vulnerability has been discovered, where under certain
circumstances, system integrity may be compromised. This may be in the form
of improper file or privilege management. Digital has corrected this potential
vulnerability.
PROBLEM: (QAR 43844) (Patch ID: OSF350-133)
********
If the 2nd argument (source array) to strncat() points to a location in memory
where there is no null terminator between that location and the 'n'th (3rd
argument) subsequent byte and the memory immediately following this 'n'th byte
is not mapped, then the strncat() function may fail with a SEGV.
$ cat foo.c
#include
#include
#include
main()
{
int len, i;
char string1[10];
char *p;
char *startp;
len = getpagesize();
p = (char *) valloc(len*2);
mprotect(p+len, len, PROT_NONE);
p+=(len-5);
startp=p;
for(i=0;i<5;i++)
*p++='a';
string1[0]='\0';
strncat(string1, startp, 5);
printf("string1 = %s\n",string1);
}
$ cc foo.c
$ a.out
Memory fault(coredump)
PROBLEM: (QAR 41329) (Patch ID: OSF350-137)
********
Fix multiple processes from adding duplicate ut_id lines in the utmp file with
duplicate ut-id keys.
This can occur on multi-processor systems when two or more users use pututline()
with the same ut_id.
PROBLEM: (ZUO100558) (Patch ID: OSF350-153)
********
This patch fixes three problems:
1) Unsuccessful attempts to su to root were not recorded in syslog/auth.log.
2) Attempts to su to nonexistent user names were being recorded in
syslog/auth.log.
3) The username recorded in syslog/auth.log was recorded as root rather than
the users username.
This patch applies to both base level and enhanced security. The error will
appear differently depending on whether base or enhanced security has been
selected.
Beginning from a non-root account (Example: lclee)
(1) su to root using an invalid password
(2) su to a nonexistant account
(3) su to root with the correct password
Examine the file /var/adm/syslog.dated//auth.log
tail /var/adm/syslog.dated//auth.log
If the system is running BASE security and needs the patch
(1) Mar 1 14:21:30 industrial su: BADSU lclee on /dev/ttyp0
(2) Mar 1 14:23:58 industrial su: BADSU lclee on /dev/ttyp0
(3) Mar 1 14:24:06 industrial su: SU lclee on /dev/ttyp0
If the system is running ENHANCED security and needs the patch
(1) no message
(2) Mar 1 14:23:58 industrial su: BADSU root on /dev/ttyp0
(3) Mar 1 14:24:06 industrial su: SU root on /dev/ttyp0
If the system has the patch applied (base or enhanced)
(1) Mar 1 14:22:43 industrial su: BADSU lclee on /dev/ttyp0
(2) no message
(3) Mar 1 14:24:06 industrial su: SU lclee on /dev/ttyp0
PROBLEM: (QAR 43849, QAR 45014) (Patch ID: OSF350-154)
********
This patch fixes a problem with taso applications that set the malloc(3)
__sbrk_override and __taso_mode tuning parameters to true. Under these
circumstances, malloc(3) can return ENOMEM before all of the taso address
space is allocated.
A brief description of the taso feature can be found in the cc(3) reference page
where the -taso switch is documented. The malloc(3) tuning parameters are
documented on the malloc(3) reference page.
PROBLEM: (CLD MGO102122, QAR 45686) (Patch ID: OSF350-217)
********
This patch fixes a memory leak problem that occurs when strxfrm() or wcsxfrm()
executes in a locale that allows one character to substitute for another during
collation. An example is the de_DE.ISO8859-1 locale, in which "ss" is equivalent
to and may be substituted for the German sharp s. In such a locale, each
invocation of strxfrm() or wcsfrm() causes some amount of heap memory to be
leaked. When you apply this patch, the memory leak no longer occurs.
PROBLEM: (QAR 38929) (Patch ID: OSF350-217)
********
This patch also fixes some incorrect behavior in the __do_replacement()
function, which is used by both strxfrm() and strcoll(). Before the fix,
__do_replacement() might use the same string pointer for the source and
destination strings in the strcpy() function. Results were unpredictable. In
addition, __do_replacement() did not test the output buffer size to determine
if the resulting string would indeed fit in the output buffer. The patch solves
all these problems.
PROBLEM: (QAR 45694) (Patch ID: OSF350-222)
********
This patch fixes a problem in the fnmatch() routine's single-byte and multibyte
versions, which incorrectly match '?' to a null character. As a result, a
filename pattern like "???" could match not only a filename containing "aaa",
but also one containing "a" or "aa". Because the find command uses fnmatch()
for filename pattern matching, there is a chance that data files may be removed
unintentionally. An example is as follows:
% find . -name 'data???' -exec rm {} \;
This command could inadvertently remove files named "data1",
"data10", and so forth.
Note that the problem fixed by this patch occurs only when you
use locales other than the default C locale.
PROBLEM: (HPAQ46E01) (Patch ID: OSF350-236)
********
After patch OSF350-128 was installed, sendmail would generate a core dump with a
segmentation fault. The stripped sendmail does not contain a symbol table so
the core dump is hard to interpret.
To determine whether this problem exists on your system, run the following test:
(1) On the system being tested, telnet to port 25.
(2) Enter illegal commands and check whether sendmail generates a core dump.
PROBLEM: (QAR 46198) (Patch ID: OSF350-253)
********
The setlocale() function may sometimes pass a null pointer to the free()
function. This is not harmful if site applications use the memory allocation
package (malloc() and free() functions) bundled in the Digital UNIX C Library.
However, if site applications use a locally developed memory allocation package
or one included as part of a layered product, passing a null pointer to free()
may cause the applications to fail. To avoid this problem, this patch installs a
version of setlocale() that checks a pointer for null before passing the pointer
to free().
PROBLEM: (BRO100738) (Patch ID: OSF350-279)
********
When testing applications on a BSD-style device such as /dev/tty0h, the ttyslot
function returns a number matching the index into the /var/adm/utmp file.
However, when running the same program on an SVR4-style device such as
/dev/lat/622, the ttyslot function always returns zero. The problem can be
indentified easily by running the sample test program included here.
Copy the following program to ttyslot_test.c:
#include
#include
#include
#include
main()
{
printf("ttyslot() = %d\n", ttyslot());
exit(1);
}
Error messages may vary, depending on which applications are being run. When
connected to a system over an SVR4-style LAT device the application calls the
ttyslot function to locate the entry in the /var/adm/utmp file. The ttyslot
function returns zero in error because it fails to match the control terminal.
When you connect to a system over a LAT device and make a ttyslot function call
to locate the entry in the /var/adm/utmp file for the control terminal of the
current process, ttyslot() returns zero in error because it fails to match the
control terminal.
PROBLEM: (ZUO100404) (Patch ID: OSF350-003)
********
This problem is more obvious with ypserv, but it can occur on ypbind also.
If there was a heavy load on a NIS server causing more than 32 connections,
ypserv would "lose" some of them. A "netstat -an" on the system would show
many TCP connections in the "CLOSE_WAIT" state and ypserv would keep taking
up more and more of physical memory.
PROBLEM: (qar 46193) (Patch ID: OSF350-210)
********
On the master server a push is generally done automatically when a map is built
(cd /var/yp; make |
