|
|
 |
HP Services Software Patches - duv32de1as00003-19980227
|
Copyright (c) DIGITAL Equipment Corporation 1998. All rights reserved.
PRODUCT: DIGITAL UNIX [R] 3.2D-1/3.2E-1
SOURCE: DIGITAL Equipment Corporation
ECO INFORMATION:
ECO Name: DUV32DE1AS00003-19980227
ECO Kit Approximate Size: 39MB
Kit Applies To: DIGITAL UNIX 3.2D-1/3.2E-1
ECO KIT SUMMARY:
An update ECO kit exists for DIGITAL UNIX 3.2DE1. This is the aggregate,
setld-based, patch kit for DIGITAL UNIX 3.2DE1. It is a cumulative patch kit
that contains all patches that are currently available for distribution. The
patch kit provides the ability to selectively install patches.
The Release Notes and Installation Instructions document provides patch kit
installation and removal instructions and a summary of each patch. Please read
through the document prior to installing patches on your system.
Note:
At this time, the release note/installation document is only available in
postscript form. It will be available in text and HTML formats in the future.
INSTALLATION NOTES:
1. Install this kit with the dupatch utility that is included in the patch kit.
The Release Notes and Installation Instructions document provides detailed
patch installation, patch removal, and a summary of each patch. You may
need to baseline your system if you have manually changed system files on
your system. The dupatch utility provides the baselining capability.
SUPERSEDED PATCH LIST:
This patch kit supersedes the following DIGITAL UNIX patches:
DUV32DE1AS00002-19970918 ! Previous Aggregate Patch Kit
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.
===============================================================================
SUPERSEDES PATCHES: OSF360-350104 (106.00)
This patch corrects the following:
- Fixes a problem where processes will hang in an uninterruptable state while
using NFS loopback mounts.
- Kernel memory fault in ubc_sync_iodone().
PROBLEM: (MCPMC8AC6) (Patch ID: OSF360-350104)
********
The panic was seen when a large number (~150) of "fastdd" is run using
seperate LSM raw volumes and writing to UFS files. UBC must be constrained
as follows:
ubc-minpercent=1
ubc-maxpercent=20
...
13 boot() [arch/alpha/machdep.c":1679, 0xfffffc000045a674]
14 panic() [bsd/subr_prf.c":757, 0xfffffc0000419d54]
15 trap() [arch/alpha/trap.c":1213, 0xfffffc0000468600]
16 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004578a4]
17 ubc_sync_iodone() [vfs/vfs_ubc.c":1022, 0xfffffc0000298ddc]
18 ufs_rwblk() [ufs/ufs_vnops.c":4427, 0xfffffc000027a488]
19 ufs_writepages() [ufs/ufs_vnops.c":5385, 0xfffffc000027c15c]
20 ufs_putpage() [ufs/ufs_vnops.c":5187, 0xfffffc000027bc38]
21 ubc_page_alloc() [vfs/vfs_ubc.c":2144, 0xfffffc000029ba00]
22 ubc_lookup() [vfs/vfs_ubc.c":1789, 0xfffffc000029aa70]
23 ufs_getapage() [ufs/ufs_vnops.c":4797, 0xfffffc000027afbc]
24 ufs_getpage() [ufs/ufs_vnops.c":5112, 0xfffffc000027ba5c]
25 ufs_rwip() [ufs/ufs_vnops.c":5859, 0xfffffc000027cd44]
26 ufs_write() [ufs/ufs_vnops.c":1771, 0xfffffc0000276b00]
27 vn_write() [vfs/vfs_vnops.c":932, 0xfffffc00002973a0]
28 rwuio() [bsd/sys_generic.c":1071, 0xfffffc0000250bec]
29 write() [bsd/sys_generic.c":996, 0xfffffc0000250a78]
30 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc0000467474]
31 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc0000457694]
PROBLEM: ( HPAQC3A71 ) (Patch ID: OSF360-024)
********
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 as follows:
THIS IS THE STACK TRACE FOR THE CLIENT:
> 0 thread_block() [kern/sched_prim.c":1903
1 mpsleep() [bsd/kern_synch.c":441
2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631
3 clntkudp_callit() [rpc/clnt_kudp.c":1008
4 rfscall() [nfs/nfs_subr.c":837
5 rfs3call() [nfs/nfs_subr.c":974
6 nfs3commit() [nfs/nfs3_vnodeops.c":3754
7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528
8 ubc_page_alloc() [vfs/vfs_ubc.c":2145
9 ubc_lookup() [vfs/vfs_ubc.c":1789
10 page_lookup() [msfs/bs/bs_buffer2.c":872
11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218
12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877
13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371
14 fs_write() [msfs/fs/fs_read_write.c":515
15 msfs_write() [msfs/osf/msfs_vnops.c":1547
16 vn_write() [vfs/vfs_vnops.c":932
17 rwuio() [bsd/sys_generic.c":1071
18 write() [bsd/sys_generic.c":996
19 syscall() [arch/alpha/syscall_trap.c":519
20 _Xsyscall() [arch/alpha/locore.s":1094
THIS IS THE STACK TRACE FOR THE SERVER THREAD WHICH WOKE UP TO HANDLE
THE ABOVE CLIENT's REQUEST:
> 0 thread_block() [kern/sched_prim.c":1891
1 mpsleep() [bsd/kern_synch.c":441
2 clntkudp_callit_addr() [rpc/clnt_kudp.c":631
3 clntkudp_callit() [rpc/clnt_kudp.c":1008
4 rfscall() [nfs/nfs_subr.c":837
5 rfs3call() [nfs/nfs_subr.c":974
6 nfs3commit() [nfs/nfs3_vnodeops.c":3754
7 nfs3_putpage() [nfs/nfs3_vnodeops.c":3528
8 ubc_page_alloc() [vfs/vfs_ubc.c":2145
9 ubc_lookup() [vfs/vfs_ubc.c":1789
10 page_lookup() [msfs/bs/bs_buffer2.c":872
11 bs_pinpg_one_int() [msfs/bs/bs_buffer2.c":3218
12 bs_pinpg_clone() [msfs/bs/bs_buffer2.c":2877
13 bs_pinpg() [msfs/bs/bs_buffer2.c":2371
14 get_clean_pg() [msfs/bs/ms_logger.c":1495
15 lgr_writev_ftx() [msfs/bs/ms_logger.c":1258
16 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719
17 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215
18 ftx_done_n() [msfs/bs/ftx_routines.c":968
19 msfs_fsync() [msfs/osf/msfs_vnops.c":1650
20 rfs3_commit() [nfs/nfs3_server.c":5671
21 rfs_dispatch() [nfs/nfs_server.c":6333
22 nfs_rpc_input() [rpc/svc.c":717
23 nfs_input() [nfs/nfs_server.c":5492
24 nfs_thread() [nfs/nfs_server.c":5277
THIS IS THE STACK TRACE FOR A SERVER THREAD WHICH WOKE UP TO HANDLE
THE ABOVE SERVER's REQUEST:
> 0 thread_block() [kern/sched_prim.c":1891
1 thread_sleep() [kern/sched_prim.c":1581
2 _cond_wait() [msfs/bs/ms_generic_locks.c":592
3 _lk_lock() [msfs/bs/ms_generic_locks.c":931
4 lgr_writev_ftx() [msfs/bs/ms_logger.c":1236
5 log_donerec_nunpin() [msfs/bs/ftx_routines.c":2719
6 ftx_done_urdr() [msfs/bs/ftx_routines.c":1215
7 ftx_done_n() [msfs/bs/ftx_routines.c":968
8 bs_sync_bf_flush() [msfs/bs/bs_qio.c":2402
9 msfs_fsync() [msfs/osf/msfs_vnops.c":1608
10 rfs3_commit() [nfs/nfs3_server.c":5665
11 rfs_dispatch() [nfs/nfs_server.c":6333
12 nfs_rpc_input() [rpc/svc.c":717
13 nfs_input() [nfs/nfs_server.c":5492
14 nfs_thread() [nfs/nfs_server.c":5277
FILE(s):
/usr/sys/BINARY/vm_cfg.o subset OSFBIN360
CHECKSUM: 25005 7 RCS: vm_cfg.c Revision: 1.1.31.2
/usr/sys/BINARY/vfs_ubc.o subset OSFBIN350
CHECKSUM: 54617 54 RCS: vfs_ubc.c Revision: 1.1.118.3
===============================================================================
SUPERSEDES PATCHES: OSF360-003 (3.00), OSF360-037 (37.00)
This patch corrects the following:
- A problem in which PATHWORKS client does not see all the files in a directory
when the directory is an NFS mounted OpenVMS UCX exported directory.
- Fixes a problem in which mmap activity to a file that is NFS mounted may
cause the client process to hang after the file is deleted.
- Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
PROBLEM: (BRO100600) (Patch ID: OSF360-003)
********
Large memory growth of ucred structures can occur. This is especially
prevalent if a user is using setuid programs.
PROBLEM: ( QAR 33924 ) (Patch ID: OSF360-037)
********
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: OSF360-050)
********
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 OSFBIN360
CHECKSUM: 55715 42 RCS: nfs_vnodeops.c Revision: 1.1.104.7
/usr/sys/BINARY/nfs3_vnodeops.o subset OSFBIN360
CHECKSUM: 30307 50 RCS: nfs3_vnodeops.c Revision: 1.1.56.3
===============================================================================
The ar command's -x option, which extracts archive files, may, in error, return
a message stating that the file was not found.
PROBLEM: ( DJOB3K133, QAR 46595 ) (Patch ID: OSF360-062)
The ar command's -x option, which extracts archive files, may
in error, return a message stating that the file was not found.
To duplicate the problem, create a library with the command
'ar r /tmp/foo.a /tmp/bar.o'.
Issuing the command 'ar -x /tmp/foo.a /tmp/bar.o' will generate
the message "ar: Error: /tmp/bar.o not found" even though the
file exists in the archive.
With the fix, the same command extracts /tmp/bar.o from /tmp/foo.a
without generating an error message.
FILE(s):
/usr/ccs/lib/cmplrs/cc/ar subset OSFBASE360
CHECKSUM: 32059 376 RCS: ar.c Revision: 4.2.33.2
===============================================================================
This patch allows system managers to both set and obtain quotas for users and
groups which are numeric when using the edquota, vedquota, quota and vquota
programs. It also provides new options to allow them to specify userids and
groupids.
PROBLEM: (HPXQ87072, QAR 46521) (Patch ID: OSF360-064)
********
This patch allows system managers to both set and obtain quotas
for users and groups which are numeric when using the edquota, vedquota,
quota and vquota programs. It also provides new options to allow them to
specify userids and groupids.
In the past, when the input to these commands was a numeric username or
groupname, the commands would either report that the name couldn't be found,
or would interpret it as the wrong user or group
(when the name coincidentally matched a valid userid or groupid).
For circumstances where the user wishes to specify userid or groupid the
-U and -G options have been added.
This correction also extends the edquota and vedquota prototype
option to allow convenient use of names and ids. In the past a numeric
argument to the "-p" option was incorrectly considered an id, not a name.
Now, the argument to "-p" will always refer to a name while the argument
to the new option "-P" will refer to an id.
Examples
To apply the quotas of user1 to user2, specifying both by their names:
edquota -p user1name user2name
To apply the quotas of user1 (specified by id), to user2 (specified by id):
edquota -P user1id -U user2id
Also, note that new versions of the message catalogue files are issued
for each of the programs. These must be updated only if they are on the
system.
FILE(s):
/usr/lib/nls/msg/en_US.ISO8859-1/edquota.cat subset OSFBASE350
CHECKSUM: 26567 2
/usr/lib/nls/msg/en_US.ISO8859-1/quota.cat subset OSFBASE350
CHECKSUM: 60092 1
/usr/sbin/edquota subset OSFBASE360
CHECKSUM: 04271 112 RCS: edquota.c Revision: 4.2.29.2
/usr/sbin/quota subset OSFBASE360
CHECKSUM: 09257 112 RCS: quota.c Revision: 4.2.39.2
rquotaxdr.c Revision: 4.2.4.2
/usr/sbin/vedquota subset OSFADVFS360
CHECKSUM: 12029 576 RCS: vedquota.c Revision: 1.1.28.2
/usr/sbin/vquota subset OSFADVFS360
CHECKSUM: 12573 504 RCS: vquota.c Revision: 1.1.25.2
===============================================================================
SUPERSEDES PATCHES: OSF360-048 (48.00)
This patch corrects the following:
- An AlphaServer 2100 or 2100A system with more than 1GB of memory
will not boot when the dma window size is set in the sysconfigtab file.
Typically the dma window size is set in the sysconfigtab file
when Memory Channel is being used.
- The Unix kernel crashes during installation if the memory in the system
exceeds 1GB. This has only been seen on AlphaServer 2100A class systems
with greater than 1GB of memory.
PROBLEM: ( QAR 43423 ) ( Patch ID: OSF360-048 )
********
This patch fixes a problem in which an Alphaserver 2100 system
with more than 1GB of memory will not boot when the dma window size
is set in the sysconfigtab file. Typically the dma window size is set in
the sysconfigtab file when Memory Channel is being used.
PROBLEM: (EMZB83716, QAR 48019) (Patch ID: OSF360-069)
********
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
...
FILE(s):
/usr/sys/BINARY/kn450.o subset OSFHWBIN360
CHECKSUM: 07156 56 RCS: kn450.c Revision: 1.1.123.2
===============================================================================
SUPERSEDES PATCHES: OSF360-350030 (84.00), OSF360-042 (42.00)
This patch corrects the following:
- A problem that occurs with the NCR 53C8XX driver (psiop) in which the device
may not appear to be on the SCSI bus.
- Data corruption due to change in DNAD register behavior on Symbios
810A/825A/860/875 chips.
- At boot, when probing the psiop driver, the system may continuously loop
generating the following error message:
"siopintr: interrupt for non-initialized controller"
PROBLEM: (QAR 36371) (Patch ID: OSF360-350030)
********
At boot, when probing the psiop driver, the system may continuously loop
generating the following error message:
"siopintr: interrupt for non-initialized controller"
This error rarely occurs. Our test cases only encountered it when continuously
rebooting for 18+ hours. To cause the machine to reboot, the system usually
started a "shutdown -r now" as part of the bootup sequence
PROBLEM: ( QAR 46878 ) (Patch ID: OSF360-042)
********
This data corruption problem is difficult to detect as no error report, etc
is given when it occurs. The data corruption can be identified by the
pattern in the corrupted data. Commonly, at the point of corruption, there
will be 3 bytes of unknown data inserted into the valid data stream.
This problem is induced by a chip register behavior change between the 810
and 810a. The register (DNAD) is used to calculate the next dma address
whenever a dma transfer is interrupted by a phase change by the scsi device.
This problem can be reproduced using the UEG engineering test script
"dt_tag_rotate_sh" which tests unaligned data accesses.
PROBLEM: (49240) (Patch ID: OSF360-072)
********
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/include/io/cam/siop/pci_scripthost.h subset OSFBINCOM350
CHECKSUM: 32364 16 RCSfile: pci_scripthost.h RCS: 1.1.35.2
/usr/sys/BINARY/psiop.o subset OSFHWBIN360
CHECKSUM: 15604 171 RCSfile: psiop.c RCS: 1.1.72.4
/usr/sys/BINARY/psiop_pci.o subset OSFHWBIN350
CHECKSUM: 09149 26 RCSfile: psiop_pci.c RCS: 1.1.55.2
===============================================================================
SUPERSEDES PATCHES: OSF360-038 (38.00)
This patch corrects the following:
- This patch fixes a Token Ring transmission timeout. The driver can experience
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.
- The token ring driver, when storing the product_id, can cause corruption
which can result in a kernel read access panic.
PROBLEM: ( UVO104380, HPAQ47704 ) (Patch ID: OSF360-038)
********
The corruption caused by the token ring driver can result in
an invalid memory read access from kernel mode panic.
The significant indicator is the faulting virtual address,
being repeated 'ef'. A representative example follows:
trap: invalid memory read access from kernel mode
faulting virtual address: 0xefefefefefeff28f
pc of faulting instruction: 0xfffffc00005675e4
ra contents at time of fault: 0xfffffc000056b54c
sp contents at time of fault: 0xffffffff87dc6a20
PROBLEM: (HPAL83FE3) (Patch ID: OSF360-075)
********
This patch fixes a Token Ring transmission timeout. The driver can experience
"ID 380PCI20001 (8/13/95)" as described in the TI380PCI Errata.
FILE(s):
/usr/sys/BINARY/if_tra.o subset OSFHWBIN360
CHECKSUM: 56424 66 RCSfile: if_tra.c RCS: 1.1.58.5
===============================================================================
SUPERSEDES PATCHES: OSF360-060 (60.00)
This patch corrects the following:
- Probe of isp fails intermittently during boot.
- A number of problems have been fixed in the ISP driver. These include:
"minimum spl violation" panics with lockmode=4, simple lock time limit
exceeded panics, "CAM_ERROR entry too large" messages, and "Unable to
restart Qlogic(LUN queue after abort)" panics.
PROBLEM: ( TKTB52828, QAR 42761 ) (Patch ID: OSF360-060)
********
This patch fixes a situation in which a system panics, displaying the string:
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: OSF360-060)
********
This patch fixes a situation in which a system panics, displaying the text:
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: OSF360-060)
********
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: OSF360-060)
This patch fixes a situation in which a system panics, displaying the string:
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: OSF360-077)
********
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 OSFHWBIN360
CHECKSUM: 16959 88 RCSfile: isp1020.c RCS: 1.1.95.3
/usr/sys/include/io/cam/qlogic/isp1020.h subset OSFBINCOM360
CHECKSUM: 55748 43 RCSfile: isp1020.h RCS: 1.1.63.3
===============================================================================
SUPERSEDES PATCHES: OSF360-052 (52.00)
This patch corrects the following:
- Fixes "simple_lock: time limit exceeded" panics coming from ctape_close()
or ctape_strategy() routines.
- Fixes "simple_lock: time limit exceeded" panic.
PROBLEM: (MCPM36085) (Patch ID: OSF360-052)
********
A "simple_lock: time limit exceeded" panic will be seen originating
from the ctape_close() routine. The stack trace is as follows:
6 panic("simple_lock: time limit exceeded")
7 simple_lock_fault()
8 simple_lock_time_violation()
9 ctape_close()
10 speclose()
11 spec_close()
12 ufsspec_close()
13 vn_close()
14 closef()
15 close()
16 syscall()
17 _Xsyscall()
PROBLEM: (UVO104133) (Patch ID: OSF360-052)
********
A "simple_lock: time limit exceeded" panic will be seen originating
from the ctape_strategy() routine. The stack trace is as follows:
9 panic("simple_lock: time limit exceeded")
10 simple_lock_fault()
11 simple_lock_time_violation()
12 ccmn_rsq_ccb_bld()
13 ctape_strategy()
14 physio()
15 ctape_write()
16 spec_write()
17 ufsspec_write()
18 vn_write()
19 rwuio()
20 write()
21 syscall()
22 _Xsyscall()
PROBLEM: (MCPMB61A4) (Patch ID: OSF360-078)
********
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 OSFHWBIN360
CHECKSUM: 19996 146 RCSfile: cam_tape.c RCS: 1.1.73.3
===============================================================================
Allows getty to accept uppercase usernames.
PROBLEM: (HPXQ86E65, QAR 49170) (Patch ID: OSF360-081)
********
This patch allows getty to accept uppercase usernames. This makes getty
consistent with the login and telnet commands.
Previously, getty would convert a terminal to display and accept
only uppercase letters if a username was entered in uppercase.
FILE(s):
/usr/sbin/getty subset OSFBASE360
CHECKSUM: 10492 168 RCSfile: getty.c RCS: 4.3.38.2
===============================================================================
Fixes a situation where a system with an S3 Trio64 graphics card set at
1280x1024 resolution does not correctly display the cursor.
PROBLEM: (QAR 42672) (Patch ID: OSF360X-002)
********
On a system with an S3 Trio64 graphics card set at a resolution of
1280x1024, the cursor does not display correctly.
FILE(s):
/usr/shlib/X11/lib_dec_s3.so subset OSFSERPCI360
CHECKSUM: 44094 144 RCS: 1.1.19.2 (s3curs.c) RCS: 1.1.22.2 (s3io.c)
RCS: 1.1.13.2 (s3init.c)
===============================================================================
SUPERSEDES PATCHES: OSF360-350061 (88.00)
This patch corrects the following:
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM: (SSRT0329U, USG-01683) (Patch ID: OSF360-350061-1)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
FILE(s):
/usr/bin/rdist subset OSFINET350
CHECKSUM: 57410 88 RCS: 4.2.21.2 (server.c)
---------------------
===============================================================================
The bootp daemon appends a null character to file names in its responses.
PROBLEM: (BRO100554) (Patch ID: OSF360-350073)
********
The bootp server daemon, /usr/sbin/bootpd, appends a null byte to filenames
in its responses. Some BOOTP clients will fail to boot when they receive
these responses. The response packets will contain the null byte appended to
any filenames and the cooresponding length fields will count the null byte.
FILE(s):
/usr/sbin/bootpd subset OSFINET350
CHECKSUM: 13480 72 RCS: 4.2.25.2 (bootpd.c), 1.1.8.2 (dovend.c),
--------------------- 4.2.12.2 (readfile.c)
===============================================================================
Fixes "timeout table overflow" panic on multiprocessor system.
PROBLEM: (QAR 39990) (Patch ID: OSF360-350079)
********
Fixes "timeout table overflow" panic on multiprocessor system.
FILE(s):
/usr/sys/BINARY/lwc.o subset OSFBIN350
CHECKSUM: 01403 6 RCS: 1.1.17.2 (lwc.c)
----------------------
===============================================================================
Corrections to tftpd when using interface aliases, bind() uses the client's
address received rather than INADDR_ANY. This fix accomodates bootpd when
used with ASE for failover purposes.
PROBLEM: (HPAQA69B2,QAR40362) (Patch ID: OSF360-350089)
********
Attempting to tftpd to an aliased interface will give
"ICMP Destination unreachable" messages when multiple
read requests are required to transfer data.
Typical Error Messages are "ICMP Destination unreachable" or "Port unreachable".
To reproduce the problem, tftp to an aliased interface and transfer a file
larger than 512 bytes. The transfer will require multiple read requests
and will return an error on the second read request.
FILE(s):
/usr/sbin/tftpd subset OSFINET350
CHECKSUM: 34261 32 RCS: 4.2.11.2 (tftpd.c)
---------------------
===============================================================================
Fix acctcms hash table overflow error.
PROBLEM: (TKTQ22355) (Patch ID: OSF360-350096)
********
When there are more than 1000 different commands in the accounting
source files, acctcms gives the error "Hash table overflow. Increase
CSIZE" and ignores the command accounting records of those commands
in excess of 1000. This problem can also be seen when running
runacct, the daily accounting procedure, because it uses acctcms
FILE(s):
/usr/sbin/acct/acctcms subset OSFACCT350
CHECKSUM: 65141 32 RCS: 4.2.18.2 (acctcms.c)
---------------------
===============================================================================
Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.
PROBLEM: (QAR 39134) (Patch ID: OSF360-350097)
********
Program translated with FreePort Express (SunOS --> Digital UNIX)
binary translator does not run correctly.
The problem is due to calls to mmap() specifying /dev/zero.
The address returned was other than the address (hint) provided.
Compile and run the following program to verify the problem exists:
#include
#include
#include
#include
main(argc, argv)
int argc;
char **argv;
{
int fd;
char *addr;
if((fd = open("/dev/zero", O_RDWR)) == -1) {
perror("mmap: open");
exit(1);
}
if((addr = mmap(0x20000000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE, fd, 0L)) == (void *)-1) {
perror("mmap: mmap");
exit(1);
}
close(fd);
if (addr == (char *)0x20000000)
printf("SUCCESS\n");
else
printf("FAILURE: mapped /dev/zero at address 0x%lx\n", addr);
exit(0);
}
FILE(s):
/usr/sys/BINARY/devz.o subset OSFBIN350
CHECKSUM: 00497 6 RCS: 1.1.10.2 (devz.c)
---------------------
===============================================================================
Fixes a problem where a system, with a RAID set for a dump device, will not
save the crash dump to the RAID set after a panic.
PROBLEM: (MCPMA0101) (Patch ID: OSF360-350100)
********
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: 48832 15 RCS: 1.1.25.2 (ruby_common.c)
---------------------
===============================================================================
Program using libexc.a suffer corrupted signal masks.
PROBLEM: (EVT101544) (Patch ID: OSF360-350102)
********
Programs linked with the libexc.a library can have their process
signal masks corrupted while handling exceptions at runtime. The
problem shows up when the process stops responding to signals.
The ps -s command shows a mask of random signals blocked, including
the one required to make the program function correctly.
Ada and C++ programs seems to the most likely to experience the
program.
FILE(s):
/usr/ccs/lib/cmplrs/cc/libexc.a subset OSFCMPLRSEXT350
CHECKSUM: 53872 23
---------------------
===============================================================================
Correct nfs server duplicate request problem, by adding timestamps.
PROBLEM: (MGO101612) (Patch ID: OSF360-350109)
********
Fixes file corruption on a Digital UNIX NFS fileserver serving
a sole single non-Digital NFS client. Problem originally encountered
when the only client was an OS/2 client.
You need this patch if you observe server corruption and can bypass
that corruption by setting the kernel global variable 'kudp_usedrc' to
zero.
Do not consider turning off duplicate record checking (drc) as a solution.
Instead, please use this patch to correctly fix this problem.
FILE(s):
/usr/sys/BINARY/svc_kudp.o subset OSFBIN350
CHECKSUM: 50175 85 RCS: 1.1.23.2 (svc_kudp.c)
===============================================================================
Running tip(1) consumes about 45% of cpu time, resulting in no idle time, even
if tip is about the only thing running on the system.
PROBLEM: ( SOO100598 ) (Patch ID: OSF360-350111)
********
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: 50008 120 RCS: tip.c Revision: 4.2.21.2
tipout.c Revision: 4.2.4.3
===============================================================================
A potential security vulnerability has been discovered where under certain
circumstances users may gain unauthorized access. Digital has corrected this
potential vulnerability.
PROBLEM: (QAR 41986) (Patch ID: OSF360-350112)
********
Users could use lattelnet to invoke a subshell, a potential security issue in
some installations.
FILE(s):
/usr/sbin/lattelnet subset OSFLAT350
CHECKSUM: 19166 24 RCS: 1.1.16.2 (lattelnet.c)
---------------------
===============================================================================
Card lockup problem using the ATM IP convergence module.
PROBLEM: (HPXQC2E60,QAR 42749) (Patch ID: OSF360-350115)
********
Card lockup problem using the ATM IP convergence module.
How to recognize the problem:
In the kern.log file you can see messages similar to:
Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50
and if you have set up a simple test between two systems using a ping over
the ATM interface, you will see that the signalling between VC's which have
been sending and receiving throughout the test will suddenly stop receiving
packets. The VC's will continue to be able to send packets.
How to reproduce the problem:
Setup two nodes A and B connected through a FORE switch and an ATM IP
PVC between the two.
From node B, issue the ping command over ATM IP. (leave the ping command
running)
On node A, remove the ATM IP PVC which is receiving the ping using the command
"atmconfig -pvc driver=lta0 vpi=0 vci=50"
In the kern.log file you will see a message like:
Dec 19 11:06:47 bcaryf03 vmunix: received 144 bytes for non-existent VC 50
and the output of an atmconfig vclist long will show you that the signalling
between VC's sending and receiving throughout the test will suddenly stop
receiving packets.
FILE(s):
/usr/sys/BINARY/if_otto.o subset OSFATMBIN350
CHECKSUM: 20751 40 RCS: 1.1.19.2 (if_otto.c)
---------------------
===============================================================================
This patch fixes a problem where a system with more than one PCI bus will fail
to configure the loadable device drivers.
PROBLEM: ( QAR 42593 ) (Patch ID: OSF360-350116)
********
System 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: 06069 16 RCS: stanza_resolver.c Revision: 1.1.15.3
/usr/sys/BINARY/pci.o subset OSFHWBIN350
CHECKSUM: 19084 26 RCS: pci.c Revision: 1.1.95.2
/usr/sys/BINARY/ldbl_controller_support.o subset OSFHWBIN350
CHECKSUM: 22052 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: OSF360-350117)
********
A system hang or a SCSI bus hang will be experienced, when using KZMSA and
HSZ40 s.
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: 52150 21 RCS: sim_sched.c Revision: 1.1.64.3
/usr/sys/BINARY/sim_as.o subset OSFHWBIN350
CHECKSUM: 46563 5 RCS: sim_as.c Revision: 1.1.21.3
===============================================================================
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.
PROBLEM: (QAR 43968) (Patch ID: OSF360-350136)
********
The system panics with kernel memory fault, and the fault_pc is in the
u_anon_free() routine.
> 0 stop_secondary_cpu() [arch/alpha/cpu.c":357, 0xfffffc00004d97a8]
1 panic() [bsd/subr_prf.c":669, 0xfffffc000043d5ac]
2 event_timeout() [arch/alpha/cpu.c":706, 0xfffffc00004da258]
3 xcpu_puts() [bsd/subr_prf.c":810, 0xfffffc000043d864]
4 printf() [bsd/subr_prf.c":355, 0xfffffc000043cbb4]
5 panic() [bsd/subr_prf.c":719, 0xfffffc000043d71c]
6 trap() [arch/alpha/trap.c":1213, 0xfffffc00004edbd0]
7 _XentMM() [arch/alpha/locore.s":1307, 0xfffffc00004dce74]
8 u_anon_free() [vm/u_mape_anon.c":2261, 0xfffffc00003840e4]
9 u_anon_unmap() [vm/u_mape_anon.c":1617, 0xfffffc0000382970]
10 u_map_delete() [vm/vm_umap.c":1188, 0xfffffc000039c650]
11 u_map_deallocate() [vm/vm_umap.c":436, 0xfffffc000039af80]
12 vm_map_deallocate() [vm/vm_map.c":611, 0xfffffc0000391698]
13 task_deallocate() [kern/task.c":472, 0xfffffc00002d6b0c]
14 waitf() [bsd/kern_exit.c":1497, 0xfffffc0000243b94]
15 wait4() [bsd/kern_exit.c":1220, 0xfffffc0000243738]
16 syscall() [arch/alpha/syscall_trap.c":519, 0xfffffc00004eca44]
17 _Xsyscall() [arch/alpha/locore.s":1094, 0xfffffc00004dcc64]
The crash can be reproduced by running the following sample program:
/*
* compile as follows:
* cc vm_deallocate_tail.c -lmach
*/
main(int argc, char **argv)
{
long addr;
int ret;
/*
* Create a >4G region
* The system must have >4G swap or must be running in lazy mode
* (/sbin/swapdefault is not present).
*/
addr = 0;
if (ret = vm_allocate(task_self(), &addr, 0x100000000UL, 1)) {
mach_error("vm_allocate:", ret);
exit(1);
}
/*
* deallocate the last page
*/
if (ret = vm_deallocate(task_self(),
addr+0x100000000UL-0x2000, 0x2000)) {
mach_error("vm_deallocate:", ret);
exit(1);
}
exit(0);
}
FILE(s):
/usr/sys/BINARY/vm_anon.o subset OSFBIN360
CHECKSUM: 06632 73 RCS: vm_anon.c Revision: 1.1.36.2
===============================================================================
SUPERSEDES PATCHES: OSF360-350054 (86.00)
This patch corrects the following:
- "ufs_getapage: allocation failed" panic.
- Applications that continuously map and unmap large data files hang in
uninterruptable state.
PROBLEM: (uvo103444) (Patch ID: OSF360-350054)
********
The user's large data base application would hang in an uninterruptible state
after running for a while. The process could not be terminated by any user
action except to reboot the system.
The user's program was memory mapping large data files, and was continually
unmapping and remapping pages of the file. Eventually the process would hang
in an uninterruptible state when it tried to write to a part of the mapped file
that was swapped out.
Here is a typical stack trace of a thread hung in this condition:
thread_block
lock_read
ufs_getpage
u_vp_fault
vm_fault
trap
_XentMM
bcopy
uiomove
ufs_rwip
ufs_write
vn_write
rwuio
write
syscall
Running in lockmode=4 produced a panic with the message:
"lock_read: lock already owned by thread"
instead of a hung process.
PROBLEM: (Patch ID: OSF360-350139)
********
The system panics with "ufs_getapage: allocation failed" message.
A typical stack trace is as follows:
panic()
ufs_getapage()
ufs_getpage()
u_vp_fault()
u_map_fault()
vm_fault()
trap()
_XentMM()
FILE(s):
/usr/sys/BINARY/ufs_vnops.o subset OSFBIN350
CHECKSUM: 41837 133 RCS: 4.2.130.2 (ufs_vnops.c)
---------------------
===============================================================================
A call-share executable with a text, data or bss region greater than 4 gbytes,
the application will segment fault.
PROBLEM: (QAR 43033) (Patch ID: OSF360-350143)
*******
A call-share executable with a text, data or bss region
greater than 4 gbyte application will segment fault.
As a work around you can build your application non-share.
This test demonstrates the problem:
csh> cat test.c
#define ARRAY_SIZE (1024*1024*512) - 1
long buf1[ARRAY_SIZE];
main()
{
printf("sizeof(buf1) = 0x%lx\n", sizeof(buf1));
buf1[1] = 42;
buf1[ARRAY_SIZE-2] = 169;
}
csh> cc test.c
csh>
csh> a.out
Segmentation fault (core dumped)
csh>
FILE(s):
/sbin/loader subset OSFBASE350
CHECKSUM: 23677 112
---------------------
===============================================================================
Using Peer Server 1.3 ECO1 and token ring network interface(s), source routing
discovery is not working as expected. Additional interfaces will not
initialize and links between remote stations cannot be established.
PROBLEM: ( MCPM26D74/QAR 43974 ) (Patch ID: OSF360-350144)
********
After installing and configuring Digital Peer Server version 1.3, EC01, token
ring source routing tables may not be built correctly. If you have multiple
token ring interfaces, additional interfaces will not initialize and links
between remote stations cannot be established.
How to recognize the problem:
Typical error messages will appear with multiple interfaces indicating
unreliable connections. You may observe console messages similar to the
following:
Event: Link Halted
from: Node 0:. LLC2 SAP sna-1 Link msamss-1
at : 1996-02-12-12:35:28.984-05:00I-----
Link Halted Reason = Implementation Specific
Check source routing module level:
"srconfig -rc" command displays several failures with no responses for
ARE packets. One may not notice these errors if source routing was
not enabled
Check at Applications level:
The applications like Peer server may not be able establish links with
remote SNA nodes. This can be verified with NCL command:
ncl> show sna cp serv t g * all
The above command displays status of the Transmission Groups as either
"Idle" or "On-connecting".
FILE(s):
/usr/sys/BINARY/trn_sr.o subset OSFHWBIN350
CHECKSUM: 44629 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: OSF360-350149)
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: 21487 19 RCS: dlproc.c Revision: 1.1.13.2
===============================================================================
A potential security vulnerability has been discovered, where under certain
circumstances users may "gain unauthorized access" to the system. Digital
has corrected this potential vulnerability.
PROBLEM: (SSRT0376X) (Patch ID: OSF360-350152)
********
A potential security vulnerability has been discovered, where under certain
circumstances users may gain unauthorized access to the system.
FILE(s):
/etc/sia/OSFC2_matrix.conf subset OSFC2SEC350
CHECKSUM: 51764 3 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: OSF360-350155)
********
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: 28646 288 RCS: latctl.c Revision: 1.1.21.2
===============================================================================
Corrects system panic with the message "pnvram_write: Timed-out DMA".
PROBLEM: (HPXQ35E83) (Patch ID: OSF360-350156 )
********
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: 35244 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: OSF360-350161 )
********
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: 55047 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: OSF360-350167)
********
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: 12594 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: OSF360-350169)
********
The DEC SNA PeerServer product instantiates a new (protocol engine) daemon that
connects to the mold daemon component of the Common Agent each time an incoming
request is received by the DEC SNA PeerServer product from the network.
The PeerServer product can handle hundreds of requests per minute, each time
starting and then stopping its protocol engine daemon that connects to the mold
daemon. The mold daemon does not clean up the socket connection that gets
created each time the PeerServer creates a new connection to the mold, leaking
several thousand bytes of virtual memory per connection, plus leaves the socket
connection dangling.
Over time, the mold component can consume all available virtual memory, causing
unpredictable results and system performance degradation. Ultimately, the
customer is forced to stop and restart the PeerServer product, which is not
acceptable to the customer, as this process is very resource intensive and can
take many minutes to complete.
Errors may get logged in the /var/adm/syslog.dated//daemon.log file,
including messages similar to these (t21mcd and t21mad are DEC SNA PeerServer
daemon components; mold is a Common Agent daemon component):
t21mcd[1184]: Daemon process t21mad(1188)
terminated, signal=6
t21mcd[1184]:
Started daemon process t21mad (3617)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
last message repeated 6 times
t21mcd[1184]: Daemon process t21mad(3617)
terminated, signal=6
t21mcd[1184]:
Started daemon process t21mad (3892)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
last message repeated 6 times
t21mcd[1184]: Daemon process t21mad(3892)
terminated, signal=6
t21mcd[1184]: Started daemon process -
t21mad (3910)
mold[324]: S011 - mold_*() call failed -
(MAN_C_OBJECT_ALREADY_EXISTS)
etc., etc.
FILE(s):
/usr/sbin/mold subset OSFCOMAGENT350
CHECKSUM: 12809 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
===============================================================================
This patch fixes a problem where the find command returns a invalid status
code upon encountering a file in an "ffm" set.
PROBLEM: (MCPM269A8) (Patch ID: OSF360-350176)
********
The find command will return a code of 2 (EINVAL) upon encountering a file
in an "ffm" set, generally associated when System V environment is being used.
When this happens, the user's application receives an invalid status code;
the system does not crash or hang.
FILE(s):
/usr/sys/BINARY/ffm_vfsops.o subset OSFBIN350
CHECKSUM: 03234 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: OSF360-350185)
********
After yppasswd has been run, NIS passwd dbm files will have read and write
permissions for other users:
-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byname.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byname.pag
-rw-rw-rw- 1 root system 0 Nov 30 11:17 passwd.byuid.dir
-rw-rw-rw- 1 root system 1024 Nov 30 11:17 passwd.byuid.pag
FILE(s):
/usr/sbin/rpc.yppasswdd subset OSFINET350
CHECKSUM: 58754 32 RCS: rpc.yppasswdd.c Revision: 4.2.15.2
===============================================================================
This patch resolves a problem with "strsetup -i -f" creating duplicate major
and minor numbers.
PROBLEM: (MCPM41A3D) (Patch ID: OSF360-350186)
********
After running "strsetup -i -f" /dev/streams/kinfo and /dev/streams/strkinfo
can have the same major and minor numbers. This causes "netsetup" to report
"ioctl: invalid argument" errors.
FILE(s):
/usr/sbin/strsetup subset OSFCLINET350
CHECKSUM: 48913 32 RCS: strsetup.c Revision: 4.2.29.2
===============================================================================
This patch adds support for file system ids ffm and nfsv3.
PROBLEM: (MCPM4AD1A) (Patch ID: OSF360-350190)
********
This patch adds support for file system ids ffm and nfsv3.
Previous to this patch, the sysfs system call
would give the following error message:
"sysfs: Function not implemented"
FILE(s):
/usr/sys/BINARY/kern_sysfs.o subset OSFBIN350
CHECKSUM: 61927 5 RCS: kern_sysfs.c Revision: 1.1.16.2
/usr/sys/include/sys/fsid.h subset OSFBINCOM350
CHECKSUM: 38534 3 RCS: fsid.h Revision: 1.1.8.2
===============================================================================
This patch resolves the condition that results when there is no default shell
in the password file causing rexecd to fail.
PROBLEM: (UVO103915) (Patch ID: OSF360-350191)
********
If a user uses chsh(1) to change their shell to /bin/sh then the
shell definition in the password file for that user is removed. This is
standard BSD behavior and the system defaults all such password entried to
/bin/sh at login time.
rexecd(8) however has a problem with accounts like this and fails
to run commands issued from programs using the rexec(3) library function.
FILE(s):
/usr/sbin/rexecd subset OSFCLINET350
CHECKSUM: 39000 24 RCS: rexecd.c Revision: 4.2.12.2
===============================================================================
This patch fixes a problem in which the rcp program fails when the file being
copied is greater than 2 Gigabytes in size. The error message from rcp is:
"connection closed".
PROBLEM: (QAR 36912, QAR 45643 ) (Patch ID: OSF360-350198)
********
This patch fixes a problem in which the rcp program fails
when the file being copied is greater than 2 Gigabytes in size.
The error message from rcp is: "connection closed".
FILE(s):
/usr/bin/rcp subset OSFCLINET350
CHECKSUM: 21511 32 RCS: rcp.c Revision: 4.2.20.2
===============================================================================
SUPERSEDES PATCHES: OSF360-350200 (166.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: OSF360-350200-1)
********
This patch fixes a problem in which the output from the df
command displays incorrectly formatted columns.
The problem occurs because the number of inodes in Digital
UNIX is quite large. This causes the columns displayed by
the df command to run together.
To reproduce the problem:
Run /bin/df -i and examine the output
FILE(s):
/sbin/df subset OSFBASE350
CHECKSUM: 58038 128
/usr/bin/df subset OSFBASE350
CHECKSUM: 49441 24 RCSfile: df.c RCS: 4.3.29.2
===============================================================================
SUPERSEDES PATCHES: OSF360-350056 (87.00), OSF360-350056-1 (87.01)
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: (HPAQ282B7) (Patch ID: OSF360-350056-1)
********
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: OSF360-350418)
********
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: 23025 152
/usr/bin/nawk subset OSFBASE350
CHECKSUM: 23025 152 RCSfile: lib.c RCS: 1.1.15.2
RCSfile: lex.l RCS: 1.1.13.2
RCSfile: b.c RCS: 1.1.14.2
===============================================================================
SUPERSEDES PATCHES: OSF360-350206 (171.00)
This patch corrects the following:
- Problem where "ping -p ff" results in a segmentation fault and core dump.
PROBLEM: (QAR 45312) (Patch ID: OSF360-350206-1)
********
"ping -p ff" results in a segmentation fault and core dump.
FILE(s):
/usr/sbin/ping subset OSFCLINET350
CHECKSUM: 53783 32 RCS: ping.c Revision: 4.2.23.2
===============================================================================
NIS slaveservers will not accept a push from the master server of a new map.
PROBLEM: (qar 46193) (Patch ID: OSF360-350210)
********
On the master server a push is generally done automatically when a
map is built (cd /var/yp; make |
