PROBLEM: (86294, different) (PATCH ID: OSF520-008) ******** cp(1) and cat(1) produce different file sizes when reading from a tape device. PROBLEM: (94735, PROBLEM, 86294, reading) (PATCH ID: OSF520-750) ******** This patch fixes the performance problem with cp with respect to the Change in the I/O buffer size from 64K to 8K that went to the support pools. This patch also fixes a problem in which cp(1) and cat(1) produce different file sizes when reading from a tape device The soultion was to change the I/O buffer size of cp to 64K and change the I/O buffer size of cat to 64K. PROBLEM: (93731, 94019, 94188, 94379) (PATCH ID: OSF520-624) ******** Added newly supported devices; added HP support for COMPAQ-branded devices PROBLEM: (94820) (PATCH ID: OSF520-752) ******** This change addes latent device recognition support for MSA1000 storage array controllers. Formal support is still dependent on successful completion of qual. Enhance SuperDLT maximum transfer size edit to be more tolerant of previous changes. PROBLEM: (93957) (PATCH ID: OSF520-564) ******** New ddr tables provide device recognition support for our latest high end tape drive, the SDLT160/320. Without the tables density and compression setting would not be possible. The drive would operate as a 'generic' tape device. Customers would not see any benefit from purchasing the newest, faster, highest density drive we have available in the DLT product line. PROBLEM: (94953) (PATCH ID: OSF520-786) ******** This patch is necessary in order for Tru64 to recognize the Ultrium 2 tape drive. And device classes AIT and Travan which are planned for future suppot. PROBLEM: (93731) (PATCH ID: OSF520-785) ******** Latent support for logical devices. PROBLEM: (none) (PATCH ID: OSF520-842) ******** Provides support for the Ultrium tape drive. PROBLEM: (88548, No) (PATCH ID: OSF520-666) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (HPAQB1F1V) (PATCH ID: OSF520-025) ******** This patch fixes a problem in which the "mv" command will not perform a move if the inode of the file is the same as the inode of the destination directory, even though said file and directory reside on different file systems. PROBLEM: (89942) (PATCH ID: OSF520-105) ******** Enabler for Enterprise Volume Manager product. PROBLEM: (90910, FR_G02528) (PATCH ID: OSF520-226) ******** This patch prevents a vold from core dumping when removing a disk from rootdg using voldiskadm or voldg. An example of the stack trace from an unstriped vold: 10 raise(0x3ff801229d8, 0x100000006, 0x3ff801869b4, 0x0, 0x3ff801a9c44) [0x3ff 801869b0] 11 abort(0x12007f66c, 0x17a4, 0x3ff80577ae0, 0x0, 0x600000000) [0x3ff801a9c40] 12 clsm_update_devs(dg = 0x140019d00, pending = 1) ["../../../../../../src/usr /sbin/lsm/clsm/vold/clsmintf.c":3711, 0x12007f668] 13 vold_dm_dis_da(dm = 0x1400ae400, clnt = 0x140018f80, remove = 1) ["../../.. /../../../src/usr/sbin/lsm/common/vold/da.c":1763, 0x120024288] 14 req_dm_dis_da(clnt = 0x140018f80, req = 0x3ffc0641170) ["../../../../../../ src/usr/sbin/lsm/common/vold/da.c":1582, 0x120023d24] More (n if no)? 15 request_loop() ["../../../../../../src/usr/sbin/lsm/common/vold/request.c": 568, 0x120061d50] 16 main(argc = 2, argv = 0x11fffc018) ["../../../../../../src/usr/sbin/lsm/com mon/vold/main.c":708, 0x120050420] PROBLEM: (90665, GB_G02495) (PATCH ID: OSF520-331) ******** This patch prevents a KMF (kernel memory fault) panic, in voldiskiostart(), when an I/O is attempted on an lsm device that is not accessible. A typical stack trace follows: 14 panic 15 trap 16 _XentMM 17 voldiskiostart 18 volkiostart 19 spec_strategy 20 read_raw_page 21 get_raw_vd_attrs 22 bs_bfdmn_tbl_activate 23 bs_bfset_activate_int 24 bs_bfset_activate 25 advfs_mountfs 26 msfs_mount 27 cfs_do_pfs_mount 28 cfs_fo_handle_pfs_mounting 29 cfs_fo_handle_bid_accept 30 cfs_fo_thread PROBLEM: (83901) (PATCH ID: OSF520-318) ******** This patch fixes a situation in which when a cluster member fails, mirrored volumes are left in a state such that recovery is always necessary when members boot, even if no additional recovery should be necessary. The problem is that without this fix a node booting does not clear its own recovery flags after recovery has completed. This results in volumes being recovered at every node boot, even if the volume was never marked dirty on the node being booted. PROBLEM: (86483, 92796, 90530, 91558, 92215, 92229) (PATCH ID: OSF520-447) ******** PROBLEM: Cannot create new diskgroups when vold is in noloadbalance mode. LSM appears to have a problem creating diskgroups when vold is in "noloadbalance" mode. # volsetup dsk2 dsk3 Checking for an existing LSM configuration Initialize vold and the root disk group: Add disk dsk2 to the root disk group as dsk2: Addition of disk dsk2 as dsk2 succeeded. Add disk dsk3 to the root disk group as dsk3: Addition of disk dsk3 as dsk3 succeeded. Initialization of vold and the root disk group was successful. # vold -k -r reset -d ; voldctl stop # vold -x noloadbalance # voldisksetup -i dsk4 # voldg init tstdg dsk4 lsm:voldg: ERROR: Disk group tstdg: cannot create: Disk group has no valid configuration copies Problem appears to be that NOLOADBALANCE code disables config/log allocation. This needs to be special cased to allow for DG creation. PROBLEM: LSM does not work correctly with third-party disks. # ls /dev/qb qa15a qa15c qa15e qa15g rqa15a rqa15c rqa15e rqa15g temp qa15b qa15d qa15f qa15h rqa15b rqa15d rqa15f rqa15h # voldiskadd qa15 No matching disks were returned. # disklabel -rwn /dev/qb/rqa15c # disklabel -r /dev/qb/rqa15c # /dev/qb/rqa15c: type: unknown disk: qd label: flags: bytes/sector: 512 sectors/track: 64 tracks/cylinder: 256 sectors/cylinder: 16384 cylinders: 128 sectors/unit: 2097152 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: . . . # voldiskadd qa15 No matching disks were returned. PROBLEM: Cluster nodes can panic during boot trying to enable a non-existent klog object. Node 1: ______ malloc: zero-size request from: ffffffff0008ea8c trap: invalid memory read access from kernel mode faulting virtual address: 0xfffffe04fe417f30 pc of faulting instruction: 0xffffffff00042ef0 ra contents at time of fault: 0xffffffff00042ef0 sp contents at time of fault: 0xfffffe072bfef800 panic (cpu 0): kernel memory fault Node 2: ______ ics_mct: Node 1 is now down clsm_sync_peer_disks: failure sending sync data clsm: sync dumpDisks() failed! clsm: failed to sync peer PROBLEM: Vold can dump core if an old configuration database exists on a disk. PROBLEM: When cluster_root is under lsm control, minimal information is available prior to cluster root being mounted. Error messages were being printed for devices which are under lsm control, but not part of rootdg. PROBLEM: It is possible on a large configuration for lsm to start before the kernel to kernel sync has completed. This is very bad as it can cause panics, proposal collisions, and other unexpected behavior. The fix blocks LSM from starting in user mode until the sync has been completed, or an attempt that failed due to a lack of peer configurations that were capable of syncing had also completed. PROBLEM: (90741, 90746, 90759, 90809, 90830, 90875, 91002, 91353, 91497, 92735, 92870, 93570, 91688, 92773) (PATCH ID: OSF520-542) ******** PROBLEM: Vold autoconfiguration problem in a cluster If LSM discovers new LSM disks, each cluster member will create a separate record for each disk, resulting in multiple records for the same disk. The new disks are discovered via the "voldctl enable" command. If an LSM disk is cloned in hardware, for example, and made available to Tru64 UNIX, and then to LSM by running the "voldctl enable" command, the following output will appear, assuming dsk10 is a new disk and this is a 3-node cluster. # voldctl enable # voldisk list DEVICE TYPE DISK GROUP STATUS dsk0 sliced - - unknown dsk1 sliced - - unknown dsk2 sliced dsk2 rootdg online dsk3 sliced - - unknown dsk4 sliced - - unknown dsk5 sliced - - unknown dsk6 sliced - - unknown dsk7 sliced - - unknown dsk8 sliced dsk8 dg1 online dsk9 sliced dsk9 dg1 online dsk10 sliced - - online dsk10 sliced - - online dsk10 sliced - - online The autoconfiguration functionality in vold was not being distributed properly. With this fix, newly discovered disks will be treated as a configuration change and other cluster members will then get up to date, not treat the disk as newly discovered even if another member has already found it. PROBLEM: Loss of LSM volume special device files after a "voldctl enable" call The "voldctl enable" command was not being distributed properly in a cluster such that newly discovered LSM volumes could be ignored by other cluster members and their corresponding special devices files could be removed. With this fix, all disk groups should be up to date before processing a "voldctl enable" call, thus accounting for newly discovered volumes. PROBLEM: volsave problem saving LSM disk flags The volsave command was not saving the "reserved" or "spare" LSM disk flags, meaning they could not be restored automatically. With this fix, volsave will save the "reserved" and "spare" disk flags if appropriate. The volrestore command will restore them if appropriate. As a result, the volclonedg command was updated to take advantage of this new functionality, so if the parent disk group has these flags set on any of its disks, the clone disk group will as well. Note that this functionality is necessary to ensure the disk group clone has the same configuration as its parent. PROBLEM: cannot run volsave from one cluster member and volrestore from another If the volsave command is run from one cluster member, and then volrestore is run from another, the following volrestore error will occur. # volrestore LSM configuration was saved on host tender.zk3.dec.com Use -f option to override this warning and restore configuration on host track.zk3.dec.com The volsave and volrestore commands were using local host information in a cluster, rather than clusterwide information. With this fix, they will use the information in the /etc/vol/volboot file, not the local hostname, so if in a cluster, the cluster alias will be used. PROBLEM: volsave command not displaying variables when I18N turned on If i18n is turned on, meaning the message catalog is being used to output messages, the volsave command is not displaying variables, as shown in the following example. # volsave LSM configuration being saved to LSM Configuration saved successfully to The volsave command is not displaying the directory name. With this fix, the variables are exported properly. Therefore, commands such as volclonedg, which parse the output of volsave, will be able to run properly. PROBLEM: The volclonedg command has an option, -r, that allows users to specify "no recovery" for mirored volumes. If any plexes were detached from a volume in the parent disk group, they should be detached in the clone disk group to avoid data integrity issues. This ensures future recovery of that volume uses the most up-to-date data plex. This fix checks the parent disk group for volumes with detached plexes and makes sure they are detached in the clone disk group. Volclonedg uses the volrestore command to get information about the parent disk group from it's associated volsave metadata. This fix also makes sure the volrestore command is run minimally, thus keeping the time it will take to run volclonedg reasonable and avoid scalability issues. PROBLEM: The volclonedg command will not set up the disk group clone configuration properly if the disk clones were created on a different host or cluster. The volclonedg command uses the volrestore command to restore the configuration. With this fix, it uses the "-f" option to volrestore to ignore host or cluster name checks. Without this fix, the volclonedg command will not be able to create the disk group clone configuration. PROBLEM: The volclonedg command does not work if any disks in the disk group to clone has a nopriv disk. That is correct behavior. However, the command is also failing if ANY disk group has a nopriv disk, not just the disk group to clone. This fix enables volclonedg to use the volsave metadata saved from the parent disk group to determine if it has any nopriv disks, thus using the appropriate LSM configuration information. PROBLEM: (92566, 90844, ORNG-617, DK_G02609) (PATCH ID: OSF520-589) ******** This patch allows the proper synchronization of disk errors and failures in a cluster under CLSM control. Before the patch the command: "voldisk list" will not be consistent on all nodes after a voldisk rm is executed on a failing or failed disk. The output on the node where the disk was removed will remove it. However all other nodes will still show the disk with 'error' as its status. On one of the nodes where the voldisk rm command was not executed: dsk103 sliced - - error - - orange02 orange removed was:dsk103 On node where voldisk rm was executed only the disk media information was displayed, as expected. - - orange02 orange removed was:dsk103 PROBLEM: (88526, 88541, 88562, wc.sec.002.ssrt) (PATCH ID: OSF520-791) ******** 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 access. HP has corrected this potential vulnerability. PROBLEM: (DSATM0D2R, 93380, HPAQ50CLP) (PATCH ID: OSF520-747) ******** This patch corrects performance issues on starting of Cluster Logical Storage Manager with large configurations. PROBLEM: (88488) (PATCH ID: OSF520-790) ******** 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 access. HP has corrected this potential vulnerability. PROBLEM: (89390, HPAQK1D53, HPAQ51LNHH, TKT360311, DE_G04616, SE_G04994) (PATCH ID: OSF520-754) ******** This patch is to prevent vold from core dumping on booting with the message: commit: not holding dg lock PROBLEM: (93135) (PATCH ID: OSF520-837) ******** This code change to the volreconfig command will prevent inconsistent LSM volumes when the name of a volume is the same as that created by a volencap of a disk partition. An example would be to have as an existing volume "vol-dsk2b", and to later conduct a "volencap dsk2b" to encapsulate that partition, which creates a default name for the volume of "vol-dsk2b". PROBLEM: (95147, 95058) (PATCH ID: OSF520-843) ******** When using LSM's volclonedg command to clone a LSM disk group whose underlying disks have been snapped or cloned in hardware, a new disk group is created. If there was a filesystem on one of the LSM volumes in the parent disk group, we now have a copy of that data. When trying to mount the filesystem on the new volume, the vold on another cluster member was dumping core and the new disk group was deported. This only occurred when smsd was running. The problem is smsd queries cluster members for information and may do so from each cluster member. If the cluster member is out of date with respect to the LSM configuration, we may get LSM configuration errors. PROBLEM: (BCGM30SD2) (PATCH ID: OSF520-019) ******** This patch fixes a volrecover error of "Cannot refetch volume" when volumes exist only in a non-rootdg diskgroup. PROBLEM: (89919) (PATCH ID: OSF520-163) ******** clu_mibs is a SNMP agent. However it's currnetly not managed by the central SNMP control script, /sbin/init.d/snmpd. The fix improves user control of the start and stop of clu_mibs by adding it into /sbin/init.d/snmpd. PROBLEM: (94472, SSRT2301) (PATCH ID: OSF520-651) ******** A potential security vulnerability has been discovered in the HP Tru64 UNIX operating system, where under certain circumstances, system integrity may be compromised through improper file access (overwriting of files). This potential vulnerability is in the form of a local security domain risk. The following potential security vulnerability has been corrected: o SSRT2301 uudecode (Severity - Medium) PROBLEM: (86560) (PATCH ID: OSF520-012) ******** This patch fixes a problem in netrain. Netrain interface creation now fails if any of the requested standby interfaces do not exist. PROBLEM: (90648) (PATCH ID: OSF520-171) ******** This patch permits configuration of smaller (< 1 second) NEtRAIN traffic monitoring timers. This in turn enables faster (< 5 second) NetRAIN failover. PROBLEM: (94533) (PATCH ID: OSF520-672) ******** The patch adds support to ifconfig for the IPv6 flag 'ip6reachabletime'. This flag sets the amount of time, in millisecons, that any neighboring node is considered reachable for the purposes of IPv6 Neighbor Discovery. PROBLEM: (81979, 87188, BCSM41XV7) (PATCH ID: OSF520-017) ******** This patch fixes a class scheduler semaphore race condition. PROBLEM: (90694) (PATCH ID: OSF520-322) ******** There have been reported cases of the class_admin command hanging at command startup. There is some evidence to suggest that in some of these cases, an external program incorrectly modifies the class scheduler semaphore - leaving it in a locked state. This fix detects this situation and on class_schedulre startup, ensures that the semaphore is set to the correct unlocked state. In addition, should the semaphore be incorrectly locked while the class scheduler is active, a diagnostic warning is printed - making it easier to diagnose this condition. PROBLEM: (STL261650) (PATCH ID: OSF520-222) ******** The class scheduler depends on semaphores to protect its database from simultaneous updates. A semaphore ID is allocated the first time the class scheduler is accessed after booting. Should this semaphore be inadvertently deleted (via ipcrm(2), for instance), the class scheduler will fail with the following message: class_database_lock: Invalid argument class_database_unlock: Invalid argument This patch automatically detects that the semaphore no longer exists and allocates a new one, allowing the class scheduler to proceed without interruption. PROBLEM: (89411, IPMT, Request) (PATCH ID: OSF520-066) ******** This problem was seen primarily on systems with hundreds or thousands of simultaneous logins, pop/imap, telnet, etc. requests occurring. Depending on the number and speed of the processor logins would take anywhere from 1 to 4 minutes to complete. Analysis of the running system would not seem to indicate a heavy CPU load. PROBLEM: (88661) (PATCH ID: OSF520-011) ******** While running in a Asian multibyte locale, commands that make use of the regcomp() and regexec() regular expression routines in libc, such as sed, may sometimes fail to find a match for a simple string that starts with a multibyte character. This patch fixes that regular expression matching problem. PROBLEM: (89594, CFS.86011) (PATCH ID: OSF520-088) ******** The -ignore_all_versions and -ignore_version flags for the run-time loader (/sbin/loader) broke in the Tru64 UNIX V5.1 release. This patch fixes those two flags. PROBLEM: (84672, 90634) (PATCH ID: OSF520-173) ******** This patch fixes a problem in the strtod() routine where it could return different results for the same inputs. It also corrects a problem where the tanl() and atanl() math functions would return the wrong results. PROBLEM: (90649) (PATCH ID: OSF520-176) ******** This patch contains two fixes. First, it fixes a memory leak with dlclose() in the libc library when an application is linked with threads. The second fix is a behavior modification with the optional dynamic loader -allocator_range and -allocator flags. These flags are now implemented as -preallocated_range. The description of -preallocated_range follows. -preallocated_range The -preallocated_range option specifies the lower and upper addresses (inclusive) of a preallocated memory region for the loader to load libraries into. The address-range parameter consists of two hexadecimal values separated by a colon. For example: -preallocated_range 20000000000:200ffffffff The address range required for any library must fall either entirely outside or entirely within the range specified with -preallocated_range. No segment loaded in the range can conflict with the link address of any other previously loaded segment in the range. This option is invalid with executables utilizing the SUID executable bit. When -preallocated_range is specified, if the loader is loading an an image linked in the preallocated address range, the loader copies the image into memory. It never performs an mmap(), munmap(), or mprotect() call on addresses in preallocated address range. Images linked at addresses in the preallocated address range can only be loaded at their link address, and will not be relocated if they cannot. PROBLEM: (117-1-18543:BCSMA04Q4:CFS.87236, 90176) (PATCH ID: OSF520-234) ******** Applications which call the mktime() function with a tm struct containing a non-negative tm_isdst (daylight savings time - DST) setting that does not match the actual DST setting for the specified time in the given time zone may be returned an adjusted tm struct (and associated time_t value) that is not accurate. This occurs only in certain time zones, and only in those containing transitions for more than one standard (STD) or DST setting. PROBLEM: (SSRT0781U) (PATCH ID: OSF520-288) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of network programs core dumping. Compaq has corrected this potential vulnerability. PROBLEM: (91301, SSRT0771U) (PATCH ID: OSF520-291) ******** When the LANG and LOCPATH environment variables are set to a very long string, the application may crash with segmentation fault. This patch fixes the problem. PROBLEM: (117-1-18105:, 82714) (PATCH ID: OSF520-272) ******** This patch fixes a problem in which the rpc tcp server incorrectly tries to write to a socket that has already been closed by a client. A system which does not have this patch will see extra tcp traffic on the wire whenever a client closes a connection to the server. This superfluous write to the socket results in a SIGPIPE sent to the server process. PROBLEM: (90902, SSRT0788U) (PATCH ID: OSF520-236) ******** When the LANG environment variable is set to a very long string, some applications may crash with memory fault. This patch fixes the problem. PROBLEM: (HPAQA117F) (PATCH ID: OSF520-281) ******** This patch fixes a problem with fopen. Prior to this fix, fopen would return "File not found" if it ran out of memory while trying to open a file. With this patch, fopen will return "Not enough space" when memory is exceeded. PROBLEM: (117-1-17857:CA1Q70314, 89329) (PATCH ID: OSF520-233) ******** Applications that call fread() with large amounts of data may experience excessive I/O activity and slower performance than expected. Also, applications which issue individual fread() calls with a total data size representation that is greater than 32 bits (2^32 of data) will always read less than the requested amount due to a truncation error in fread(). This patch addresses these problems. PROBLEM: (83201,) (PATCH ID: OSF520-261) ******** Some call_shared executables that have been instrumented to analyze performance characteristics or dynamic memory usage may dump core when invoked. Attempting to debug such a core dump will result in an error message indicating the debugger cannot attach to the loader. This patch will fix the loader error that caused the core dump to occur. PROBLEM: (HPAQA117F, 91886) (PATCH ID: OSF520-280) ******** This patch fixes a problem with strerror where buffers could not be allocated. The problem occurs when a user exhausts memory, then, tries to use strerror to get the error string. Instead of the error message, the user gets a NULL return result from strerror. PROBLEM: (117-1-17467:BCSM60KGT, 74405) (PATCH ID: OSF520-232) ******** Applications that use the fwrite() library call may fail when the total number of bytes to be written is larger than 2 GB. Also, when the total number of bytes to be written is a multiple of 4 GB, fwrite() may indicate success, when in reality, no data has actually been written. This patch addresses these problems. PROBLEM: (90461) (PATCH ID: OSF520-194) ******** As described in the regexec.3 reference page, the regexec() routine compares a string to a compiled regular expression. However, a problem causes the regexec() routine to fail to find a match if the REG_NEWLINE flag of the cflags parameter is specified and the matching pattern in the given string happens to be after the first '\n' character(s). This patch fixes this matching problem. PROBLEM: (89280) (PATCH ID: OSF520-279) ******** This patch fixes a regular expression performance problem in case insensitive mode. It also fixes two potential regular expression problems for multibyte locales. PROBLEM: (90927, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-212) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (90927, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-213) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (88076, 87883) (PATCH ID: OSF520-103) ******** This patch resolves the following Event Manager issues: - Memory leaks occur in evmd when events with extended event names are posted, and when events are retrieved from the kernel corefile on the first restart following a system panic. - An event filter syntax error is reported when an event filter is used to search for events posted by a host with hyphen characters in its name. - evmwatch terminates immediately if the EVM daemon terminates, rather than continuing to run and reconnecting automatically when the daemon is restarted. PROBLEM: (90333) (PATCH ID: OSF520-153) ******** Enablers for Huron Packaged Database Solution PROBLEM: (86249, 90094) (PATCH ID: OSF520-159) ******** This patch fixes a situation in which certain errors reported through the binary error logger (binlog) are reported incorrectly by the Event Manager (EVM). The problem affects binlog events of type 113 (system console errors), which are incorrectly reported by EVM as "double error halt" events, and types 195 (StorageWorks Command Console events) and 197 (EMX fiber channel adaptor events), both of which are reported as unknown events. These problems are fixed by application of this patch. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-023) ******** A potential security vulnerability has been discovered, where under certain circumstances, users can clobber temporary files created by shell commands and utilities (e.g. under /sbin, /usr/sbin, /usr/bin, and /etc). Compaq has corrected this potential vulnerability. PROBLEM: (87037) (PATCH ID: OSF520-018) ******** This patch provides the /usr/lbin/mkstemp program which allows the mechanism to create a secure temporary file. PROBLEM: (90927, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-216) ******** PROBLEM: (90927) (PATCH ID: ) 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-214) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (87593, 90868, EVMLOGGER) (PATCH ID: OSF520-268) ******** This patch fixes a problem in which EVM clients subscribing to the cluster alias will miss events within the cluster because connections between cluster members may be lost unexpectedly. This affects any EVM client that may subscribe to the cluster alias including the EVM log manager, /usr/sbin/evmlogger. Events will be lost after an attempt to deliver a large event ( generally larger than 128 KB ) within the cluster. Normally this is not a problem. But there are events on large configurations, such as a machine state change ( FRU tabel event ) on a GS320, that can cause the problem. The problem will be seen only if the subscriber is configured to receive this event and is subscribing to the cluster alias. The connection between cluster members may not be lost immediately following the delivery of a large event. It is possible for the connection to be lost several days later if there is light system event activity. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-387) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (90927, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-241) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (89264) (PATCH ID: OSF520-276) ******** In rare circumstances it is possible for an EVM posting client or the EVM daemon to core dump if an attempt to allocate memory fails. The problem is resolved by application of this patch. PROBLEM: (90927, 91071, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-303) ******** This patch fixes the following sys_check problems: - 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 access. Compaq has corrected this potential vulnerability. - The verification of invoking processes' name in CLISCRIPT failed due to the PARSING of "ps" output. PROBLEM: (93105, 93353) (PATCH ID: OSF520-492) ******** PROBLEM: Multithreaded programs making heavy use of malloc and free may see seemingly random segfaults in unnamed routines at addresses near malloc() and free(). The routine free() is in the traceback when the core file is examined. Very occasionally, malloc() may be in the traceback instead of free(). PROBLEM: (81126) (PATCH ID: OSF520-425) ******** The sed command may perform very slowly if a regular expression that starts with ".*" is used with line joining operation. This patch fixes this performance problem. PROBLEM: (92373) (PATCH ID: OSF520-476) ******** This patch fixes a problem with printing long double values. It increases the number of significant digits printed for %Lf and %Lg formats. When the %Lf and %Lg formats were used with the printf routines, only 17 significant digits of output were provided. This fix provides 36 significant digits for long doubles. PROBLEM: (92238) (PATCH ID: OSF520-427) ******** PROBLEM: Programs which allocate many chunks from malloc and free few of them suffer degraded malloc performance. This is common in C++ applications which create many objects via the new operator. PROBLEM: (91631) (PATCH ID: OSF520-436) ******** Shared libraries that call atexit() or pthread_atfork() to register atexit or prefork handlers do not unregister the handlers if the libraries are unmapped by a call to dlclose. This condition causes a segfault when an attempt is made to invoke the handlers during an exit() or fork() operation. The patch properly unregisters the handlers that were registered by atexit() or pthread_atfork(), when the shared libraries in which they reside are unmapped by a dlclose() call. PROBLEM: (92646, 54708) (PATCH ID: OSF520-442) ******** This fix solves a performance problem with printing of arrays with a specified precision. PROBLEM: (92001) (PATCH ID: OSF520-396) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. Compaq has corrected this potential vulnerability. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-454) ******** 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 access. Compaq has corrected this potential vulnerability. As part of this correction, this patch provides two new utilities and three new libc routines. The utilities are /usr/bin/mktemp and /usr/sbin/dirclean, and the libc routines are mkdtemp(), mkstemps(), and safe_open(). This change also updates the /sbin/init.d/rmtmpfiles script and root's crontab to use /usr/sbin/dirclean. PROBLEM: (89977, 91413, 92790, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-480) ******** 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 access. Compaq has corrected this potential vulnerability. As part of this correction, this patch will modify nissetup (ypsetup) to securely create temp files in the /tmp directory. PROBLEM: (89295, 89838) (PATCH ID: OSF520-301) ******** PROBLEM: (89295, 89838) (PATCH ID: ) DEGPA and NetRAIN ----------------- DEGPA adapters will cease to communicate occasionally in a NetRAIN configuration. Investigation via ifconfig will reveal the MAC (HWaddr) addresses are the same, which is not a valid configuration. # ifconfig -va alt0: flags=c63 NetRAIN Virtual Interface: nr1 NetRAIN Attached Interfaces: ( alt0 alt1 ) Active Interface: ( alt0 ) HWaddr 0:60:6d:21:24:7b alt1: flags=c63 NetRAIN Virtual Interface: nr1 NetRAIN Attached Interfaces: ( alt0 alt1 ) Active Interface: ( alt0 ) HWaddr 0:60:6d:21:24:7b DEGPA and vMAC -------------- DEGPA adapters have not previously supported vMAC (for example with cluster alias). Clients within same subnet as cluster alias are not able to ping nor telnet their cluster alias due to the vMAC address not responding. PROBLEM: (85855) (PATCH ID: OSF520-435) ******** This patch fixes a problem with RLIMIT_DATA process limits when running fsck on a large file system. PROBLEM: (91376) (PATCH ID: OSF520-304) ******** This patch fixes "ata probe: reset failed, sts=0x7f, err=0x7f" errors for IDE disks not connected to the system. The problem is the original ata driver is expecting to get back 0xff during probing for IDE disks not connected to the system. When the driver gets 0x7f values, it thinks that a IDE disk is actually there. The driver will then attempt to get a response from that IDE disk by issuing bus resets, which will drastically slow down the boot process. The user may see the following error messages from the original ata driver during boot up when an IDE disk is not connected to the system: ata_probe: reset failed, sts=0x7f, err=0x7f ata_probe: drive 0 failed, sts=0x7f, err=0x7f cam_logger: SCSI event packet cam_logger: bus 3 target 1 lun 0 ss_perform_timeout timeout on request on the bus, scheduled bus reset Active CCB at time of error DDR - Warning: Device has no `name` - for Vendor ID : Product ID: Revision: ata0:1 Invalid PIO mode IDE device attached cam_logger: SCSI event packet cam_logger: bus 3 target 1 lun 0 ss_perform_timeout timeout on request on the bus, scheduled bus reset PROBLEM: (89636, 89818, PANIC) (PATCH ID: OSF520-118) ******** The patch updates the emx driver to v2.02 and fixes the following problems: . panic of can't grow probe list . a problem of a mcs_lock panic when an adapter experiences a h/w hang condition On large fabrics, when changes to the configuration are made more than one fabric probe can result. Having more than one fabric probe outstanding at the same time can result in a can't grow probe list panic. This version of the driver addresses this issue. Sometimes when an adapter has a hardware failure, the result can be that the communications mailbox area is left in a permanent busy state. The emx driver when trying to communicate to the adapter would wait forever while holding a lock. This could result in a mcs_lock panic. This version of the driver addresses this issue. To enable error control, the sysconfibtab must have Enable_Error_Control = 1 added to the emx section. PROBLEM: (85811, 85406, 85726, 86107, 86375, 86657, 86828, 87776, 80684, 88062, 87339, 88063, 88243, 86895, 87339, 80116) (PATCH ID: OSF520-071) ******** The patch updates the emx driver to v2.01 and fixes the following problems: . a problem of unexpected tape i/o aborts . panic of can't grow probe list . several kernel memory faults within the driver . redundant adapter failures no longer panic the system . a problem of panicing with low memory resources . stalling i/o during reprobing when a cluster member goes down. PROBLEM: (81635, 85286) (PATCH ID: OSF520-078) ******** Dynamic drivers are not getting unloaded and reloaded correctly because their ctlr_unattach() routines do not get called when unloaded. Additionally, upon subsequent loads and reloads, their probe() routines do not get called. PROBLEM: (87646) (PATCH ID: OSF520-077) ******** This patch fixes a problem where when using VX1 graphics module, mouse cursor disappears when moved along left and top most edge. PROBLEM: (87008) (PATCH ID: OSF520-126) ******** This problem is seen when debugging kernel crash dumps. The corruption is always page-aligned and usually in the sparse VM "managed" space. "kmem -v" under the "crash" analysis tool may identify this type of corruption, however this problem is not limited to kmem allocations. The corruption can take any form -- application data, kernel data, database -- depending on which wrong page happens to be selected. PROBLEM: (89626) (PATCH ID: OSF520-007) ******** This patch fixes a "simple_lock timeout" system panic due to a bug between mcs_unlock and mcs_lock_try on the same cpu. A common statck trace will look like the following: mcs_unlock_C thread_list_wakeup wakeup_prim_result .... _XentINT mcs_unlock_C PROBLEM: (none) (PATCH ID: OSF520-115) ******** This patch provides the following: - NHD4 enablers for future hardware support - A new /usr/sbin/wol command that utilizes the Wake (remotely power) feature for a future platform through the network (Lan) PROBLEM: (none, none) (PATCH ID: OSF520-121) ******** This patch provides NHD4 enables for future hardware support of a graphics device. PROBLEM: (87422) (PATCH ID: OSF520-009) ******** This patch fixes a time loss problem seen on DS systems (TSUNAMI) only when using console callbacks. The patch resynchronizes the clock when a time loss is detected. PROBLEM: (88013) (PATCH ID: OSF520-074) ******** This patch fixes a rare panic in the driver for the DE600/DE602 10/100 Ethernet adapter. The panic is the result of a kernel memory fault that occurs when an ioctl is sent to the driver (for instance using "ifconfig"), or when a machine is shutting down to reboot. Typically it will only occur when there is high traffic on the network. The stack trace may show ee_rint as the routine in which the kernel memory fault occurred: 1 panic() 2 trap() 3 _XentMM() 4 ee_rint() 5 ee_rx_intr_work_thread() The stack trace may alternatively show ee_add_rfd_buf as the routine in which the kernel memory fault occurred: 1 panic() 2 trap() 3 _XentMM() 4 ee_add_rfd_buf() PROBLEM: (90892) (PATCH ID: OSF520-207) ******** This patch provides NHD4 enablers for future hardware support of a new platform. PROBLEM: (89958) (PATCH ID: OSF520-097) ******** Domain panics and points to quotaUndo not being able to open the offending fileset, when a domain has a fileset with a clone and the clone is deleting and a file in the fileset finds no space available in the domain. PROBLEM: (CA1Q62704, 89522) (PATCH ID: OSF520-081) ******** This patch corrects a problem where the network subsystem sometimes sends a null TCP packet when a connection is reset. PROBLEM: (89942) (PATCH ID: OSF520-116) ******** Enabler support for Enterprise Volume Manager product PROBLEM: (89088, TKT205463) (PATCH ID: OSF520-044) ******** This patch fixes a system panic with "malloc_check_checksum: memory pool corrution" A vnode is being referenced after it has been freed and return to kmem. The pmsgbuf has the bucket infomation: memory pool corruption memory address: 0xfffffc00807fafc0 memory size: 0x240 ra of last caller freeing memory: 0xfffffc00004a477c panic (cpu 0): malloc_check_checksum: memory pool corruption The memory address shows that the last locker was wait_for_vxlock: (dbx) 0xfffffc00807fafc0/10X 0xfffffc00807fafc0: 0xfffffc00004a35ae 0xdeadbeefdeadbeef 0xfffffc00807fafd0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807fafe0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807faff0: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef 0xfffffc00807fb000: 0xdeadbeefdeadbeef 0xdeadbeefdeadbeef crash> 0xfffffc00004a35ae/i (dbx) 0xfffffc00004a35ae/i [wait_for_vxlock:1000, 0xfffffc00004a35ac] bsr ra, simple_unlock(line 1497) PROBLEM: (85229) (PATCH ID: OSF520-020) ******** This patch fixes a problem in which issuing a "quot -h" command causes a memory fault when the /etc/fstab file contains a mount point that is not mounted. PROBLEM: (SSRT0742U) (PATCH ID: OSF520-021) ******** A potential security vulnerability has been discovered in the kernel, where under certain circumstances a race condition can occur that could allow a non-root user to modify any file and possibly gain root access. PROBLEM: (90091) (PATCH ID: OSF520-138) ******** The user is unable to create a raw IPv6 socket with protocol other then 0 or IPPROTO_RAW. PROBLEM: (89728) (PATCH ID: OSF520-089) ******** This patch corrects a CFS problem that could cause a panic with the panic string of "CFS_INFS full". Note, this problem only exists when running in a cluster environment. PROBLEM: (90018) (PATCH ID: OSF520-128) ******** This patch fixes a problem if an error occurs while calling the DEVIOCGET ioctl, in which the user's buffer would not be filled in and would return zeros. PROBLEM: (BCGM80NF5) (PATCH ID: OSF520-075) ******** This patch fixes a problem in which a tcp socket can continue to receive data with no application running. PROBLEM: (89177, 87242, ZUO61276A) (PATCH ID: OSF520-031) ******** This patch fixes a performance problem and the results are large performance increases in configurations where more than 8 tapes are supported on a fibre channel (usually behind an MDR or FCTCII). PROBLEM: (82005) (PATCH ID: OSF520-142) ******** This patch should be installed if either of the following are true: 1) If the configuration includes any devices behind FCTCIIs or MDRs. 2) If the tape device does not properly select desired densities or compression. PROBLEM: (90118, BCGM91KNL) (PATCH ID: OSF520-141) ******** Fix problem seen in low-memory situations within task swapping code This would most frequently be seen as a panic from within thread_continue(), with a message in the pmsgbuf looking like: thread_continue: thread 0x7fe38380 in state 0x15 panic (cpu 1): thread_continue Examining the trace back of the noted thread (which is also the first argument to thread_continue()), one will find a blocking idle_thread, that looks like something along the lines of this: crash> tf > 0 thread_block src/kernel/kern/sched_prim.c : 3102 1 lock_wait src/kernel/kern/lock.c : 852 2 lock_write src/kernel/kern/lock.c : 947 3 k_map_delete src/kernel/vm/vm_kmap.c : 1419 4 kmem_stack_free src/kernel/vm/vm_kmap.c : 1151 5 stack_free src/kernel/vm/vm_kmap.c : 1288 6 thread_deallocate src/kernel/kern/thread.c : 1900 7 thread_continue src/kernel/kern/sched_prim.c : 3284 8 thread_block src/kernel/kern/sched_prim.c : 3101 9 idle_thread src/kernel/kern/sched_prim.c : 4518 PROBLEM: (87647, 88665, HPAQ617CN) (PATCH ID: OSF520-039) ******** This problem can occur if the vm_swap_wcluster parameter is not set to a page multiple. A typical stack trace my look like the following: > 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 trap 6 _XentMM 7 vm_swap_async_done 8 lwc_schedule 9 thread_block 10 xpt_callback_thread PROBLEM: (89536, 89930) (PATCH ID: OSF520-127) ******** This patch provides the following: - NHD4 enablers for future hardware support of an array controller. - Fixes to some problems found with Raid Services that include: raid services not acknowledging presence of CAM RAID device, a hang, the inability to prohibit a user from deleting a logical volume while it's in use, and a "malloc_check_checksum: memory pool corruption" system panic. 1. Devices reporting a device type of Raid are being recognized by the CAM subsystem as valid control port devices. Applications that use Raid services need to determine how many control ports are present in the system in order to gain specific information about each control. If product installed on the system that utilizes a control port (ie. CAM Raid device) and raid services doesn't acknowledge its presence then this patch should be installed. 2. Applications that use the Maintenence pass thru mode of Raid services and issue multiple pass thru commands will hang. 3. Applications that use Raid services for online deletion of logical units could delete a unit that is in use. 4. A system panic with panic string: panic (cpu 8): malloc_check_checksum: memory pool corruption The problem occurs due to an uninitialized section of a CCMN_SPECIFIC pd structure. PROBLEM: (MGO10736A, EVT0396650, TPOB36405, BCSM10NZK, BCGM5280J) (PATCH ID: OSF520-033) ******** This patch fixes a problem where threads can hang in x_load_inmem_xtnt_map() when called from x_page_to_blkmap(). A typical hung thread will have the following calls at the top of its stack trace: 0 thread_block 1 lock_read 2 x_load_inmem_xtnt_map 3 x_page_to_blkmap 4 x_page_to_iolist 5 blkmap This patch also fixes a problem where the IO transfer rate writing to a file in an AdvFS domain can suddenly drop. All of the following conditions must be met in order for this problem to occur. 1. The file must be on a multi-volume AdvFS domain. 2. The file must be sparse. That is, it must have unwritten areas within the file. 3. The file must fill its initial volume while still sparse. 4. All writes to the interior of the file will exhibit the problem after step 3. 5. All writes to the end of the file will not exhibit the problem. This problem is only seen on the specific file or files meeting the above criteria. All other files will perform normally. PROBLEM: (88816, 89170, 83043, 89185, 89301, 89352) (PATCH ID: OSF520-024) ******** This patch fixes the following Virtual Memory problems. The first three are seen on NUMA systems only, and the forth problem can be seen on any system type: Problem 1: ----------- A "vm_pg_alloc: page not free" system panic that occurs during process migration. This panic occurs because during kernel stack migration, some of the steps involved in allocating a new stack page, copying the contents from the current page, and disposing of the current page were being done in the incorrect order. Problem 2: ------------ A "vm_pageout_activate: page already active" system panic that occurs if one thread is unlocking some pages in memory while another thread is migrating them. An example stack trace would be as follows: 4 panic src/kernel/bsd/subr_prf.c : 1353 5 vm_pageout_activate src/kernel/vm/vm_pagelru.c : 2146 6 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 1978 7 u_anon_fault src/kernel/vm/u_mape_anon.c : 1463 8 u_anon_lockop src/kernel/vm/u_mape_anon.c : 3147 9 u_map_lockvas src/kernel/vm/vm_umap.c : 1540 10 memlk src/kernel/bsd/kern_mman.c : 2360 11 syscall src/kernel/arch/alpha/syscall_trap.c : 725 12 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 or: 4 panic src/kernel/bsd/subr_prf.c : 1353 5 vm_pageout_activate src/kernel/vm/vm_pagelru.c : 2146 6 u_anon_faultpage src/kernel/vm/u_mape_anon.c : 1978 7 u_anon_fault src/kernel/vm/u_mape_anon.c : 1463 8 u_map_fault src/kernel/vm/vm_umap.c : 756 9 vm_fault src/kernel/vm/vm_fault.c : 176 10 trap src/kernel/arch/alpha/trap.c : 2329 11 _XentMM src/kernel/arch/alpha/locore.s : 2143 Problem 3: ----------- Memory inconsistancies caused by fault path for large shared memory regions prematurely releasing a hold on a page it just locked. This can cause variety of problems including user program errors and system panics. The conditions under which this corruption can happen are unique. The system must be a NUMA machine in which SSM migration is enabled (it is enabled by default). Users of large shared memory regions (must be 8 MB or larger) that are also locking the shared memory while the memory is migrating could create the right set of conditions that would result in this problem. Problem 4: ------------ A "simple_lock: time limit exceeded" system panic that occurs if very large (8MB or larger) System V Shared memory regions are in use. An example stack trace would be as follows: 4 panic src/kernel/bsd/subr_prf.c : 1309 5 simple_lock_fault src/kernel/kern/lock.c : 2805 6 simple_lock_time_violation src/kernel/kern/lock.c : 2938 7 pmap_ssm_enter src/kernel/arch/alpha/pmap.c : 7827 8 u_ssm_fault src/kernel/vm/u_mape_ssm.c : 2386 9 u_map_fault src/kernel/vm/vm_umap.c : 740 10 vm_fault src/kernel/vm/vm_fault.c : 168 11 trap src/kernel/arch/alpha/trap.c : 2325 12 _XentMM src/kernel/arch/alpha/locore.s : 2115 PROBLEM: (88846) (PATCH ID: OSF520-120) ******** This patch fixes a problem with the memory troller attempting to post an EVM event indicating that a particular PFN has been mapped out. The problem stems from the post memory event attempting to delete an event that was never created. The failure to create an event is due to the troller's elevated SPL. The EVM event delete code then attempts to delete a null event which results in a failure. Symptoms would be a kernel memory fault in either post_memory_event or EvmEventDestroy. "trap: invalid memory read access from kernel mode" PROBLEM: (86244, 88931, HPAQ21NL3, 86987, 87977, BCSM51NH2) (PATCH ID: OSF520-029) ******** This patch fixes ubc performance problems and lock timeout issues. PROBLEM: (87578, 84358, 84926, 86046, 87027, 87578) (PATCH ID: OSF520-051) ******** Below are descriptions of problems that have been fixed with this patch: - There is performance related problem with applications that use mutexes which are allocated in shared memroy. This problem manifests itself when trying to allocate large quantitiies of mutexes in shared memory. - When developing applications that use mutexes which are allocated in shared memeory, unexpected EINVAL errors would appear if these mutexes and their condition variables were not in the same shared memory regions. PROBLEM: (HPAQ90Q79, BCSM40W91, 64343, 87051) (PATCH ID: OSF520-052) ******** This patch fixes a bug that can cause performance problems for certain applications when the sysconfigtab parmaeter ipc:sem_broadcast_wakeup is set to 0. Otherwise, the original behavior is preserved, which is to wake-up all threads waiting on a semaphore value change. PROBLEM: (DE_G02243, DE_G02261) (PATCH ID: OSF520-131) ******** A check for managed address may return an invalid value when called with the address of a gh region not on rad 0. A panic may occur with the following stack trace: 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 trap 6 _XentMM 7 mcs_lock_try 8 pmap_dup 9 vm_dup_va 10 volkiomem_iter 11 volkiocopyout 12 volsio_unstabilize 13 vol_mv_wrback_done 14 voliod_iohandle 15 voliod_loop PROBLEM: (BCPM205PB) (PATCH ID: OSF520-055) ******** This fixes a kernel memory fault panic in msg_rpc_trap(). An example stack trace would be: panic() trap() _XentMM() msg_rpc_trap() _Xsyscall() PROBLEM: (88778) (PATCH ID: OSF520-059) ******** There are 2 scenarios that needed to be fixed. Scenario 1: A file with a hole at page 10 is opened for cached IO and the hole is filled. Then this file is closed and opened for directIO, and page 10 is written successfully. If the system crashes before the log page describing the addition of the hole storage has been flushed to disk, then after recovery, the data written via directIO to page 10 will be lost since it will be reverted to a hole. This is an error for directIO since the write is considered "to disk", and should not return success unless the metadata has been flushed to disk. Scenario 2: This is the same scenario as above, but the thread that opens the file for directIO is a CFS client. CFS retrieves the extent maps (which are in memory only) and writes to page 10 successfully. The system then crashes and, after recovery, page 10 does not exist because the extent maps were never flushed to disk. The first scenario was fixed by setting the dirty_alloc bit in the file context when storage is added via the directIO code. This is detected in fs_write() and ensures that both the file stats and the log pages are flushed to disk before returning to the caller. This is the same as if the file were opened with the O_SYNC flag. The second scenario was fixed by modifying msfs_open() to flush the log when a file is opened for directIO iff it is being opened for a CFS file, and there is an outstanding allocation that needs to be written to disk. PROBLEM: (90110) (PATCH ID: OSF520-130) ******** This patch fixes a crash that occurs when disk controllers are restarted repeatedly. This occurs when memory associated with the disk controller is unallocated more than once. The following message is displayed: PANIC: "malloc_leak: free with wrong type" PROBLEM: (90031) (PATCH ID: OSF520-098) ******** This patch fixes a "u_shm_oop_deallocate: reference count mismatch" due to a bug in locking mechanism when gh_chunks are in use. PROBLEM: (89245, 90061) (PATCH ID: OSF520-129) ******** There is a firmware issue in the HSG80 controllers that during a cluster transistion can cause the HSG80 controllers to crash. This controller crash can then cause loss of data access to those logical volumes on that pair of HSG80 controllers. If cluster root is on that HSG80 a cluster domain panic can result. The symptoms of this problem are DRD barrier errors logged to the /usr/adm/messages files and to the console. This can also be verified by examining the HSG80 fmu logs and the HSGO console. The key text in determining this problem is as follows: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature Example output run fmu FMU> show last most Last Failure Entry: 6. Flags: 006FF901 Template: 1.(01) Description: Last Failure Event Occurred on 26-SEP-2001 at 10:10:29 Power On Time: 1. Years, 30. Days, 9. Hours, 1. Minutes, 11. Seconds Controller Model: HSG80 Serial Number: ZG02900845 Hardware Version: E05(2D) Software Version: XCF4P-0(FF) Instance Code: 0102030A Description: An unrecoverable software inconsistency was detected or an intentional restart or shutdown of controller operation was requested. Reporting Component: 1.(01) Description: Executive Services Reporting component's event number: 2.(02) Event Threshold: 10.(0A) Classification: SOFT. An unexpected condition detected by a controller software component (e.g., protocol violations, host buffer access errors, internal inconsistencies, uninterpreted device errors, etc.) or an intentional restart or shutdown of controller operation is indicated. Last Failure Code: 43230101 Last Failure Parameter[0.] 00000013 Last Failure Code: 43230101 Description: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature of the inconsistency. Reporting Component: 67.(43) Description: Host Port Protocol Layer Reporting component's event number: 35.(23) Restart Type: 0.(00) Description: Full software restart Active Thread: FOC I960 Priority: 0.(00) Interrupt Stack Guard is intact NULL Thread Stack Guard is intact Thread Stack Guard State Flags (ID# Bit; 0=intact,1=not intact): 00000000 PROBLEM: (BCSM80J37) (PATCH ID: OSF520-035) ******** This patch corrects the problem of a thread deadlocking against itself under the following conditions: o Running in a cluster. o Opening (and then closing) a directory that has an index file. o Trying to open the index file through .tags (e.g. defragment does that) and by coincidence getting the vnode that pointed to the directory that the index file is attached to. PROBLEM: (85224) (PATCH ID: OSF520-064) ******** Fix for internal kernel panic "bs_invalidate_rsvd_access_struct: bad access struct" PROBLEM: (88220) (PATCH ID: OSF520-109) ******** This patch ensures that DMAPI region information maintains consistency across CFS server and client nodes in the case that an unexpected node failure occurs. PROBLEM: (89643) (PATCH ID: OSF520-100) ******** This patch fixes a problem where additional HSZ70 control ports, /dev/cport/scpN, were created during HSZ70 controller failover operations. When this condition occurs, anyone using /usr/lbin/hsxterm5 would have trouble talking to the HSZ70 using the original control port. PROBLEM: (87934) (PATCH ID: OSF520-101) ******** This patch fixes a problem uncovered when using 'hwmgr' to delete devices with lockmode=4. When deleting a device was not successful, a lock was not released properly. Later, this dangling lock could cause a lock hierarchy violation and we would panic. PROBLEM: (HGO091469, 87558) (PATCH ID: OSF520-062) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This could result in a panic with the string: "lock_clear_recursive: recursion not enabled." Compaq has corrected this potential vulnerability. PROBLEM: (86800, 89135) (PATCH ID: OSF520-106) ******** This patch fixes a problem where new devices could be created when following the HSZ70 controller failover procedure. When this problem is encountered, you will see inconsistencies reported by the "hwmgr -show comp -i" command. PROBLEM: (QAR85485) (PATCH ID: OSF520-117) ******** This patch will fix the following problem: * Reading a clone file that is still in the cache after an rmvol may panic the system. The problem is that pages in the UBC for a clone file may end up mapped to invalid volume indexes after an rmvol. If a clone file has been read into the UBC and a subsequent rmvol removes a volume that any of the clone's non-cowed pages were mapped to, the migrate code as part of the rmvol fails to remap those pages to the new volume. If read ahead code is executed on those pages still in the UBC, the system will panic with a "trap: invalid memory read access from kernel mode" error. Here is an example stack trace: > 0 boot(reason = (unallocated - symbol optimized away), howto =(unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc0000676414] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":1401, 0xfffffc000029f220] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../ ../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006644a0] 3 _XentMM(0x0, 0xfffffc00004243d8, 0xfffffc000086b6a0, 0x0, 0xfffffc0005949008) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc000065df14] 4 seq_ahead_cont(bfap = (unallocated - symbol optimized away), bp = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away)) ["../../../../src/kernel/msfs/bs/bs_buffer2.c":6298, 0xfffffc00004243d4] 5 bs_refpg_int(bfPageRefH = (unallocated - symbol optimized away), bfPageAddr = (unallocated - symbol optimized away), bfap = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away), refHint = (unallocated - symbol optimized away), protp = (unallocated - symbol optimized away), pl = (unallocated - symbol optimized away), plsz = (unallocated - symbol optimized away), getflag = 0, rwflg = (unallocated - symbol optimized away), chkFlg = 0, fetchPages = 0, offset = 0, len = 0) ["../../../../src/kernel/msfs/bs/bs_buffer2.c":3153, 0xfffffc0000420c1c] 6 bs_refpg(bfPageRefH = (unallocated - symbol optimized away), bfPageAddr = (unallocated - symbol optimized away), bfap = (unallocated - symbol optimized away), bsPage = (unallocated - symbol optimized away), refHint = 162657712) ["../../../../src/kernel/msfs/bs/bs_buffer2.c" :2670, 0xfffffc00004203c0] 7 fs_read(0xc00, 0x0, 0x3e8000003e8, 0x0, 0xfffffc00035e3740) ["../../../../ src/kernel/msfs/fs/fs_read_write.c":4061, 0xfffffc0000488280] 8 msfs_read(vp = (unallocated - symbol optimized away), uio = (unallocated - symbol optimized away), ioflag = (unallocated - symbol optimized away), cred = (unallocated - symbol optimized away)) ["../../../../src/kernel/msfs/osf/ msfs_vnops.c":3293, 0xfffffc000049e220] 9 vn_read(0xfffffc00002b2d00, 0xfffffe0409b1f878, 0xfffffc00011eeb40, 0x1, 0xfffffe0409b1f840) ["../../../../src/kernel/vfs/vfs_vnops.c":1257, 0xfffffc00005f0958] 10 rwuio(0xfffffe0409b18000, 0xfffffc000665e700, 0xfffffc00021f5880, 0xfffffe0409b1f8f0, 0x0) ["../../../../src/kernel/bsd/sys_generic.c":2257, 0xfffffc00002b2d54] 11 read(0x7ce000, 0xfffffc0000000001, 0x2000, 0x0, 0xffffffff00000001) ["../../../../src/kernel/bsd/sys_generic.c":2206, 0xfffffc00002b2c58] 12 syscall(0x2000, 0x0, 0x0, 0x1200019a8, 0x0) ["../../../../src/kernel/arch/ alpha/syscall_trap.c":725, 0xfffffc000065a4c0] 13 _Xsyscall(0x8, 0x3ff800d1b48, 0x3ffc009e310, 0x3, 0x140006008) ["../../../ ../src/kernel/arch/alpha/locore.s":1814, 0xfffffc000065dc9c] PROBLEM: (none) (PATCH ID: OSF520-125) ******** This patch fixes a problem where a variable was used without being initialized, which could lead to a possible kernel memory fault. PROBLEM: (89942) (PATCH ID: OSF520-063) ******** New functionality, freezefs and thawfs Enablers to support the Enterprise Volume Manager product PROBLEM: (87884, 83022, 84591, 84891) (PATCH ID: OSF520-016) ******** This patch corrects several CAM errors including: passthru IOCTL fails with EIO (CAM_BUSY) problem; RESERVATION CONFLICT driver BUSY problem; enforce super user only access for SCSI passthru. PROBLEM: (86529) (PATCH ID: OSF520-096) ******** This patch enables access to SCSI control ports (/dev/cport/scp??), allowing managment of some types of RAID controllers. A system which does not have this patch will report an error of the nature shown below: Unable to open device '/dev/cport/scp0', EINVAL (22) - Invalid argument PROBLEM: (86764) (PATCH ID: OSF520-092) ******** The unintended auto-mounts create certain slow-downs which lengthens the boot process and which increases the liklihood of other mounts being slowed down. PROBLEM: (86761, 89906) (PATCH ID: OSF520-112) ******** Cluster members appear to lose communications with other members which cause one or more nodes to panic with a "This node removed from cluster" event. The machine then reboots and seems to run correctly. PROBLEM: (89215) (PATCH ID: OSF520-108) ******** This patch fixes a panic that occurs if DMAPI operations are erroneously executed on an NFS filesystem. stack trace: 1 panic 2 trap 3 _XentMM 4 kdm_k_pathtohandle 5 kdm_dmapi_ioctl 6 kdm_ioctl 7 hwc_iomap_ioctl 8 spec_ioctl 9 vn_ioctl 10 ioctl_base 11 syscall 12 _Xsyscall PROBLEM: (88985) (PATCH ID: OSF520-133) ******** Processes triggering stack growth with anon_rss_enforce set to 2, and exceeding the set resident memory limit hang (lockmode < 4) or panic (lockmode 4). A panic triggered by this problem will have the following section in its trace: panic lock_read u_anon_rss_enforce u_anon_fault u_stack_fault vm_fault PROBLEM: (84916, 89288) (PATCH ID: OSF520-137) ******** Fix for internal kernel panic "xfer_hole_stg: unaligned kernel access" -or- "xfer_hole_stg: kernel memory fault" PROBLEM: (ALC-2-076, 86181, 88669, 88057) (PATCH ID: OSF520-067) ******** 1. This patch fixes a timing window where flushing data to disk can be incomplete when a system is going down. Note this can only occur if all of these conditions are true: o More than one thread calls the reboot() system call without first going through shutdown, /sbin/reboot, or /sbin/halt (note the operating system itself does not do this, it would have to be an application program which is calling reboot()). o O_SYNC is not in use. o AdvFS data logging is not in use. 2. If a file is opened for O_DIRECTIO and O_APPEND, and several threads write data to the file expecting the data to be appended to the file, it is possible that two threads will write their data to the same offset in the file. If this happens, the data from the second thread will overwrite the data from the first. This fix ensures that the threads are properly synchronized and that all data is appended to the end of the file. 3. This patch fixes a problem with the following symptoms. a. live_dump: aio_run_completion: ACQ_UNREF not set b. vmunix: trap: invalid memory write access from kernel mode stack trace: _XentMM src/kernel/arch/alpha/locore.s : 2115 dequeue_head src/kernel/kern/queue.c : 148 aio_run_completion src/kernel/bsd/kern_aio.c : 1946 aio_rw src/kernel/bsd/kern_aio.c : 2521 syscall src/kernel/arch/alpha/syscall_trap.c : 713 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 c. Have not seen this, but there is the potential to see a thread hang waiting to reclaim a vnode with its vnode->v_numoutput being non-zero. 4. This patch fixes a condition where the smoothsync thread, in attempting to flush dirty buffers for memory-mapped files, would also flush buffers for non-memory-mapped files. This did not cause any errors, but could cause more IO than necessary to be done. Occasionally, buffers that are scheduled to be lazily written to disk get written before the normal smooth-sync scheduling. This was discovered in the routine responsible for flushing dirty memory-mapped buffers which can also flush dirty buffers for non-memory-mapped buffers. This would happen at 'smoothsync_age' intervals, which is every 30 seconds by default. PROBLEM: (FR_G01276, 86827) (PATCH ID: OSF520-032) ******** This patch allows POSIX semaphores/msg queues to operate properly on a CFS client. These mechanisms are not "clusterized" and cannot be used across nodes but any application using semaphores or message that works on a base system should also work when run on a single node in a cluster (client or server). PROBLEM: (89670, 89680) (PATCH ID: OSF520-086) ******** Qar 89670 - An error path in del_clean_mcell_list() attempts to acquire locks out of hierarchy order. This will cause a lock hierarchy violation. Qar 89680 - It is possible to read to far into a log record. This will cause a kernel memory fault to occur. PROBLEM: (88758) (PATCH ID: OSF520-111) ******** The routine msfs_unmount() could cause a hang if the underlying filesystem is currently busy. PROBLEM: (90136) (PATCH ID: OSF520-147) ******** A deadlock can occur when setting "failover" or "nofailover" on an HSZ70. The deadlock could occur if you invoke "hwmgr -show comp" during the HSZ70 requests. The deadlock will not hang your system, but it will hang the hwmgr show comp request and other hwmgr requests. PROBLEM: (BCGM7243T, TKT194594) (PATCH ID: OSF520-080) ******** This patch fixes a problem where network interfaces can appear unresponsive to network traffic. PROBLEM: (87926) (PATCH ID: OSF520-047) ******** A device that has been seen at various different paths may not be available at any one of those paths during boot. For example, a device that has been moved from one location to another, will have a previously known path that no longer exists for that device. If the system tries to access that path, the following message may be printed to indicate that the path is no longer there: Path to device has been reduced This message may be printed when a previously known path to a device is not available, even though another valid path is available to access that device. This patch limits the printing of this message at boot time to just the last path to the device. If there are any valid paths to the device, then this message will be suppressed. It continues to be important to print this message for any device which has no valid paths at all. PROBLEM: (84361, 89376, 89912) (PATCH ID: OSF520-073) ******** This fix enables the quick reclaim and deallocation of a vnode. PROBLEM: (87881) (PATCH ID: OSF520-107) ******** Under stress conditions where the DMAPI functionality is in use, a panic may occur. A fix is available for this problem. stack trace: boot panic trap _XentMM kdm_msfs_pathtohandle kdm_k_pathtohandle kdm_dmapi_ioctl kdm_ioctl hwc_iomap_ioctl spec_ioctl vn_ioctl ioctl_base syscall _Xsyscall PROBLEM: (83661, 85312, STL111443) (PATCH ID: OSF520-002) ******** This patch fixes a problem where the setgid bit of a directory was not being set when created, if its parent directory has the setgid bit set. PROBLEM: (LACCH0001, 87717, 85433, 80908) (PATCH ID: OSF520-060) ******** This patch corrects several problems in kernel routing: - Fix panic when deleting an IP address. - Fix panic when performing IP re-configuration. - Fix to add interface route on address configuration. PROBLEM: (90297) (PATCH ID: OSF520-151) ******** Fix for panic "ics_unable_to_make_progress: input thread stalled" on a clustered system running with rt_preempt_opt enabled. The stack trace of the panic will look like the following: crash> tf > 0 boot 1 panic 2 ics_mct_llassert_not_stalled 3 ics_mct_thread PROBLEM: (88975, 86987, 89590) (PATCH ID: OSF520-070) ******** This patch addresses three types of ubc system issues: Change #1 Reinstate ubc_maxpercent hard limit behavior, like V4.0f, V5.0/a. Change #2 Allows ubc to purge and steal pages under very low free memory conditions during page allocation. This is a performance enhancement to the system during very low free memory conditions. Change #3 Remove memory mapping for NFS page being invalidated and freed. Pages were being freed but still mapped to the process. PROBLEM: (89942, 89918) (PATCH ID: OSF520-113) ******** This patch is for another patch, both will be distributed together. Therefore customers will not see the symptoms that this patch addresses. PROBLEM: (HPAQ3245Q, 89096) (PATCH ID: OSF520-110) ******** This patch corrects a performance problem where NFS V3 I/O used larger than necessary buffers when writing to locked files resulting in lower throughput. PROBLEM: (89942) (PATCH ID: OSF520-123) ******** This patch provides a script that will allow a user to remove the evm patch after the version switch has been thrown by running clu_upgrade -switch. This script will set back the version identifiers and request a cluster shutdown and reboot to finish the deletion of the patch. Another rolling upgrade will be required to delete the patch with dupatch. The /usr/sbin/evm_versw_undo script must be run by root in multiuser mode after the evm patch has been completely rolled in and before another rolling upgrade has begun. A system or cluster shutdown will be required to remove the evm patch. IMPORTANT: Since the removal of a version switched patch requires a cluster shutdown only run this script when you are absolutely sure that this patch is the cause of your problem. This script must be run by root in multiuser mode after completing the rolling upgrade that installed the patch and before starting another rolling upgrade. The final removal of the patch can only be accomplished by rebooting the system or cluster after this script completes its processing. This script will offer to shutdown your system or cluster at the end of its processing. If you choose to wait it is your responsiblity to execute the shutdown of the system or cluster. DO NOT FORGET OR WAIT FOR AN EXTENDED PERIOD OF TIME BEFORE SHUTTING DOWN THE CLUSTER. CLUSTER MEMBERS WHICH ATTEMPT TO REBOOT BEFORE THE ENTIRE CLUSTER IS SHUTDOWN CAN EXPERIANCE PANICS OR HANGS. PROBLEM: (89942) (PATCH ID: OSF520-093) ******** This patch establishes a new version.id for the enabling of version switched capabilities. This patch will be interdependent on all other patches which require version switches. PROBLEM: (90396) (PATCH ID: OSF520-150) ******** The KZPEA adapter returned a Check Condition with invalid sense data. This condition is being looked for by the disk driver and will now be retried. PROBLEM: (89775) (PATCH ID: OSF520-156) ******** A root user could panic the system if an illegal argument is passed to UFS mount. Example: mount -u extend /mnt/tmp Stack trace: (dbx) t > 0 boot(reason = (unallocated - symbol optimized away), howto = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc000067b854] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/bsd/subr_prf.c":1401, 0xfffffc000029f4a0] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006696e0] 3 _XentMM(0x0, 0xfffffc000065fed4, 0xfffffc00008409a0, 0x0, 0x5de14a) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc0000663154] 4 simple_lock(0x0, 0xfffffc000065fed4, 0xfffffc00008409a0, 0x0, 0x5de14a) ["../../../../src/kernel/arch/alpha/lockprim.s":709, 0xfffffc000065fed4] 5 vrele(vp = (unallocated - symbol optimized away)) ["../../../../src/kernel/vfs/vfs_subr.c":2628, 0xfffffc00005de0c0] 6 ufs_mount(0x11fffe028, 0xfffffffe00000000, 0x0, 0x11fffaa38, 0xfffffe0428347d10) ["../../../../src/kernel/ufs/ufs_vfsops.c":1227, 0xfffffc00005b9480] 7 local_mount(0x130003600000000, 0xfffffc0000000002, 0x200, 0x3bd81bc900002000, 0x3bd81bc900000000) ["../../../../src/kernel/vfs/vfs_syscalls.c":1608, 0xfffffc00005e0294] 8 mount1(0x2, 0x3bd81bc9, 0x3bd81bc9, 0x3bd81bf9, 0x2000) ["../../../../src/kernel/vfs/vfs_syscalls.c":1767, 0xfffffc00005e0660] 9 syscall(0x14000, 0x11fffaec8, 0x0, 0xfffffe0428347900, 0x0) ["../../../../src/kernel/arch/alpha/syscall_trap.c":725, 0xfffffc000065f700] 10 _Xsyscall(0x8, 0x12005d8b8, 0x1200148c0, 0x1, 0x11fffaa38) ["../../../../src/kernel/arch/alpha/locore.s":1814, 0xfffffc0000662edc] Console message: trap: invalid memory read access from kernel mode faulting virtual address: 0x0000000000000000 pc of faulting instruction: 0xfffffc000065fed4 ra contents at time of fault: 0xfffffc00005de0c4 sp contents at time of fault: 0xfffffe0428347680 panic (cpu 0): kernel memory fault syncing disks... done PROBLEM: (QAR90619) (PATCH ID: OSF520-172) ******** This is a fix to the freezefs code that went into IPK BL0, it is not a separate patch. PROBLEM: (90504) (PATCH ID: OSF520-168) ******** Symptom: System appears hung or has poor response times. A 2-CPU system stalls while performing multiple parallel AdvFS file copies. CPU utilization drops to near zero. File copies proceed but at only a tiny fraction of their usual pace. System interactive response time is very poor even with tons of idle CPU. The same thing happens with only 1 CPU enabled also. PROBLEM: (90156, 90525, 90580) (PATCH ID: OSF520-183) ******** If you get a "panic: RDG unwire" while running with RDG and GH chunks, this patch will fix it. This scenario is especially likely to happen when running Oracle 9i, although it can happen at other times as well. PROBLEM: (QAR#90397, QAR#90784) (PATCH ID: OSF520-192) ******** The problem causes duplicate attributes to be registered for all CAM devices present in the system. A "hwmgr -get attr -id ?" command can be used to validate that the duplicate entries exist. Use the following command: > # hwmgr -get attr -id 65 | more This problem also causes duplicate statistics to be reported when CAM devices are selected. Here's an example: # iostat dsk1 dsk2 tty dsk1 dsk2 dsk1 dsk2 cpu tin tout bps tps bps tps bps tps bps tps us ni sy id 1 57 0 1 683 78 0 0 0 0 2 0 21 77 PROBLEM: (90685, 90503) (PATCH ID: OSF520-203) ******** There is a firmware issue in the HSG80 controllers that during a cluster transistion can cause the HSG80 controllers to crash. This controller crash can then cause loss of data access to those logical volumes on that pair of HSG80 controllers. If cluster root is on that HSG80 a cluster domain panic can result. The symptoms of this problem are DRD barrier errors logged to the /usr/adm/messages files and to the console. This can also be verified by examining the HSG80 fmu logs and the HSGO console. The key text in determining this problem is as follows: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature Example output run fmu FMU> show last most Last Failure Entry: 6. Flags: 006FF901 Template: 1.(01) Description: Last Failure Event Occurred on 26-SEP-2001 at 10:10:29 Power On Time: 1. Years, 30. Days, 9. Hours, 1. Minutes, 11. Seconds Controller Model: HSG80 Serial Number: ZG02900845 Hardware Version: E05(2D) Software Version: XCF4P-0(FF) Instance Code: 0102030A Description: An unrecoverable software inconsistency was detected or an intentional restart or shutdown of controller operation was requested. Reporting Component: 1.(01) Description: Executive Services Reporting component's event number: 2.(02) Event Threshold: 10.(0A) Classification: SOFT. An unexpected condition detected by a controller software component (e.g., protocol violations, host buffer access errors, internal inconsistencies, uninterpreted device errors, etc.) or an intentional restart or shutdown of controller operation is indicated. Last Failure Code: 43230101 Last Failure Parameter[0.] 00000013 Last Failure Code: 43230101 Description: During processing to maintain consistency of the data for Persistent Reserve SCSI commands, an internal inconsistency was detected. > Last Failure Parameter[0] contains a code defining the precise nature of the inconsistency. Reporting Component: 67.(43) Description: Host Port Protocol Layer Reporting component's event number: 35.(23) Restart Type: 0.(00) Description: Full software restart Active Thread: FOC I960 Priority: 0.(00) Interrupt Stack Guard is intact NULL Thread Stack Guard is intact Thread Stack Guard State Flags (ID# Bit; 0=intact,1=not intact): 00000000 PROBLEM: (90349, 90810) (PATCH ID: OSF520-196) ******** SMP and NUMA system with high load averages can see negative load averages as displayed by /usr/bin/uptime command. If this occurs, the kernel scheduler will dispatch runnable threads in an unfair manner. This can result in non-optimal performance. This patch also fixes initial placement decisions by the scheduler on NUMA platforms (GS80, GS160 and GS320). The incorrect placement will result in non-optimal performance. PROBLEM: (90555) (PATCH ID: OSF520-186) ******** This patch fixes a rmvol failure that would be seen as an E_PAGE_NOT_MAPPED error when no more space is available for user data migration to another volume in the domain. The error would appear like the following: # rmvol -F dsk2b rmvol_dmn1 rmvol: Removing volume '/dev/disk/dsk2b' from domain 'rmvol_dmn1' rmvol: Can't move file /rmvol_fset1/file12 pages rmvol: Error = E_PAGE_NOT_MAPPED (-1035) rmvol: Can't move file /rmvol_fset1/file12 metadata rmvol: Can't remove volume '/dev/disk/dsk2b' from domain 'rmvol_dmn1' PROBLEM: (87242, 90632) (PATCH ID: OSF520-191) ******** This patch fixes the following tape drive problems: - a problem where tape devices spuriously rewind or go offline. It will only allow one HBA to be selected for tape I/O because using more than one path causes a problem with the MDR queuing up Unit Attentions on more paths than the tape driver is prepared to handle. - When executing the following commands; mt -f /dev/tape/tape1_d1 rewind vdump -0 -f /dev/tape/tape1_d1 -D /etc vdump fails to close and displays the following message: vdump: unable to properly close device ; [5] I/O error An example output would be: > # mt -f /dev/tape/tape1_d1 rewind > # vdump -0 -f /dev/tape/tape1_d1 -D /etc > path : /etc > dev/fset : cluster_root#root > type : advfs > advfs id : 0x3aedd0ed.000452ac.1 > vdump: Date of last level 0 dump: the start of the epoch > vdump: Dumping directories > vdump: Dumping 2749504 bytes, 69 directories, 1062 files > vdump: Dumping regular files > vdump: Rewinding and unloading tape > > vdump: unable to properly close device ; [5] I/O error > > vdump: Status at Fri Nov 2 15:52:20 2001 > vdump: Dumped 2846062 of 2749504 bytes; 103.5% completed > vdump: Dumped 69 of 69 directories; 100.0% completed > vdump: Dumped 1062 of 1062 files; 100.0% completed > vdump: Dump completed at Fri Nov 2 15:52:20 2001 PROBLEM: (90642) (PATCH ID: OSF520-204) ******** Opening a disk partition sometimes fails when the disk is on shared bus. PROBLEM: (BCGMB0G74/90845) (PATCH ID: OSF520-201) ******** System panics with kernel memory fault. Typical stack trace were ubc page being released faults because lru is corrupt. cpu 1 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1205 1 panic src/kernel/bsd/subr_prf.c : 1252 2 event_timeout src/kernel/arch/alpha/cpu.c : 1971 3 printf src/kernel/bsd/subr_prf.c : 940 4 panic src/kernel/bsd/subr_prf.c : 1309 5 trap src/kernel/arch/alpha/trap.c : 2262 6 _XentMM src/kernel/arch/alpha/locore.s : 2115 7 ubc_page_release src/kernel/vfs/vfs_ubc.c : 4852 8 cfs_rwvp_cache src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 837 9 cfs_cacheread src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 502 10 cfs_read src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 995 11 vn_read src/kernel/vfs/vfs_vnops.c : 1250 12 rwuio src/kernel/bsd/sys_generic.c : 2264 13 read src/kernel/bsd/sys_generic.c : 2213 14 syscall src/kernel/arch/alpha/syscall_trap.c : 713 15 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 Second cpu stack trace is in ubc_written_kluster 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1205 1 panic src/kernel/bsd/subr_prf.c : 1294 2 event_timeout src/kernel/arch/alpha/cpu.c : 1971 3 mcs_lock_miss src/kernel/arch/alpha/lockprim.s : 3973 4 ubc_written_kluster_do_ubcpages src/kernel/vfs/vfs_ubc.c : 5805 5 ubc_written_kluster src/kernel/vfs/vfs_ubc.c : 5969 6 cfs_putpage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 314 7 ubc_page_alloc src/kernel/vfs/vfs_ubc.c : 3773 8 ubc_clean_page src/kernel/vfs/vfs_ubc.c : 5631 9 ubc_kluster src/kernel/vfs/vfs_ubc.c : 5734 10 cfs_getapage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 8 46 11 cfs_getpages src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 6 70 12 cfs_getpage src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 1563 13 cfs_rwvp_cache src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 791 14 cfs_cacheread src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 1 502 15 cfs_read src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 995 16 vn_read src/kernel/vfs/vfs_vnops.c : 1250 17 rwuio src/kernel/bsd/sys_generic.c : 2264 18 read src/kernel/bsd/sys_generic.c : 2213 19 syscall src/kernel/arch/alpha/syscall_trap.c : 713 20 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 PROBLEM: (90017) (PATCH ID: OSF520-205) ******** When sequentially writing files that consume all of available system memory, other users sometimes see very poor interactive response. This includes hanging ls commands and hanging logins. Processes doing the writing often show random drops in their I/O rate. This may be reproduced using multiple large "cp" or "dd" commands running in parallel in the background. PROBLEM: (94038) (PATCH ID: OSF520-221) ******** Problem: This patch fixes a potential problem in which stale data (data which is out-of-date) may be returned to an application running on a CFS client when it reads data from a file on a CFS server. Compaq has corrected this problem. Problem: An fsync() or synchronous write may return to the application before some data has been flushed to disk. The data will still be queued to go out to disk but if the system crashes before it does, the update will be lost. The amount of data that will be lost will be no greater than 8192 bytes. Compaq has corrected this problem. PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-215) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (91148) (PATCH ID: OSF520-247) ******** This problem will not be seen by customers since this bug only exists in the V51a IPK pools. The I/O Barrier code will not take a reservation on a device after registration. This will occur on new devices and new cluster installations. PROBLEM: (91287, 91302) (PATCH ID: OSF520-284) ******** HSV110 Persistent Reserve with a Reservation conflict SCSI status gets passed off to cam_notify when it should not, resulting in incorrect reservation status. The error logs will have a numbers of Reservation Conflict errors with the reporting module of cdisk_handle_pr_ccb. PROBLEM: (91142) (PATCH ID: OSF520-313) ******** This fix addresses a data inconsistency that can occur when a CFS client reads a file that was recently written to. Stale data can be returned to the client. PROBLEM: (90733) (PATCH ID: OSF520-189) ******** This fixes SEL logging problem where panic events were logged as misc events. It also adds new event types that can be logged. PROBLEM: (89045) (PATCH ID: OSF520-119) ******** While performing CPU hotswap, once a CPU is removed for added into the system, a system panic would occur. PROBLEM: (SSRT0740U) (PATCH ID: OSF520-079) ******** A potential security vulnerability has been discovered in the networking, where under certain circumstances a remote system can take over packets destined for another host. PROBLEM: (89363) (PATCH ID: OSF520-084) ******** Link Aggregation groups can successfully be created and configured. However, packets can NOT be successfully transmitted nor received over the resulting lag interface. PROBLEM: (85933, HPALA1VFH) (PATCH ID: OSF520-274) ******** This patch prevents a potential panic with non-StorageWorks raid controllers that used the same name for a controller and a disk drive. This conflict was resolved in a prior release but left open the possibility that any attempt to access this disk drive by the kernel could result in a system panic caused by a kernel memory fault. PROBLEM: (89086) (PATCH ID: OSF520-305) ******** This patch is in support of a cluster patch. PROBLEM: (90523, 91030) (PATCH ID: OSF520-248) ******** Enabling anon_rss_enforce on a NUMA system breaks with the panic line of this variety: panic (cpu 6): u_anon_oop_deallocate: anon_rss_pagelist has pages queued This will occur in a stack trace along these lines: > 0 stop_secondary_cpu 1 panic 2 event_timeout 3 printf 4 panic 5 u_anon_oop_deallocate 6 vm_map_entry_delete 7 u_map_delete 8 vm_map_exit 9 exit 10 syscall 11 _Xsyscall PROBLEM: (SSRT0759U) (PATCH ID: OSF520-237) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of file corruption due to the manner in which setuid/setgid programs core dump. Compaq has corrected this potential vulnerability. PROBLEM: (BCGMB1N21) (PATCH ID: OSF520-299) ******** This patch fixes a kernel memory fault in wait_to_readyq(), or advfs_page_busy(), or potentially other routines which may reference a vm_page, bsBuf, or ioDesc that has been freed prematurely. The following events need to be present to cause this panic. (a) It has to be on a cluster. (b) A thread has to be opening the quota.user or quota.group file with the O_DIRECTIO option . (c) At the same time the thread in (b) is opening the quota.user or quota.group file, there has to be another thread adding or deleting storage to another file on the same domain#fileset. A typical stack trace for the panicing thread is the following. 4 panic 5 trap 6 _XentMM 7 wait_to_readyq 8 check_cont_bits 9 bs_io_thread PROBLEM: (83002) (PATCH ID: OSF520-293) ******** The files were incompatible with C++ due to the usage of reserved words. PROBLEM: (90757) (PATCH ID: OSF520-309) ******** The published cam_logger() interface was modified in V5.1A to accept a hardware id in its parameter list. This patch restores the cam_logger interface to its published specifications, and introduces the cam_logger3() interface to accept a hardware id in its parameter list. PROBLEM: (90221, 91235) (PATCH ID: OSF520-316) ******** This patch addresses a problem where, under certain very rare conditions, a panic with a stack trace similar to the following could result: PANIC: "pgl_remove: remove from empty (vop)->vu_cleanpl" 4 panic src/kernel/bsd/subr_prf.c 5 ubc_page_release src/kernel/vfs/vfs_ubc.c 6 cfs_putpage src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c 7 ubc_invalidate src/kernel/vfs/vfs_ubc.c 8 vclean src/kernel/vfs/vfs_subr.c 9 vgone src/kernel/vfs/vfs_subr.c PROBLEM: (LU_G01229) (PATCH ID: OSF520-275) ******** This fixes a problem with vm_faults against anon objects mapped by multiple map entires. PROBLEM: (90551) (PATCH ID: OSF520-277) ******** Patch adds ECC information to error log. PROBLEM: (BCGMA1Q9S, 89434) (PATCH ID: OSF520-250) ******** This patch fixes a problem where decreasing the smoothsync_age does not always have an effect. PROBLEM: (86861) (PATCH ID: OSF520-193) ******** System will panic and/or data corruption may occur by changing fifo parameter pipe-databuf-size while fifo operations are in flight. Panic information: (dbx) t > 0 boot(reason = (unallocated - symbol optimized away), howto = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/machdep.c":2644, 0xfffffc000067b854] 1 panic(s = (unallocated - symbol optimized away)) ["../../../../src/kernel/ bsd/subr_prf.c":1401, 0xfffffc000029f4a0] 2 trap(a0 = (...), a1 = (...), a2 = (...), code = (unallocated - symbol optimized away), exc_frame = (unallocated - symbol optimized away)) ["../../../../src/kernel/arch/alpha/trap.c":2266, 0xfffffc00006696e0] 3 _XentMM(0x1, 0xfffffc00005d0fc0, 0xfffffc00008409a0, 0xfffffc0059d72400, 0x0) ["../../../../src/kernel/arch/alpha/locore.s":2143, 0xfffffc0000663154] 4 fifo_write(vp = (unallocated - symbol optimized away), uiop = (unallocated - symbol optimized away), ioflag = (unallocated - symbol optimized away), cred = (unallocated - symbol optimized away)) ["../../../../src/kernel/vfs/ fifo_vnops.c":1161, 0xfffffc00005d0fc0] 5 nfsfifo_write(0xfffffc00005f7044, 0xfffffc00927b00c0, 0xfffffe04a223f878, 0xfffffc0030481d40, 0xfffffe04a223f878) ["../../../../src/kernel/nfs/ nfs_vnodeops.c":3939, 0xfffffc0000533e38] 6 vn_write(0xfffffc00002b3230, 0xfffffe04a223f878, 0xfffffc004dd7f200, 0x0, 0x4000) ["../../../../src/kernel/vfs/vfs_vnops.c":1427, 0xfffffc00005f7040] 7 rwuio(0xfffffe04a2238000, 0xfffffc000cbc9880, 0xfffffc00927b00c0, 0xfffffe04a223f8f0, 0x1) ["../../../../src/kernel/bsd/sys_generic.c":2257, 0xfffffc00002b3284] 8 write(0xb4000, 0xfffffc0000000001, 0x4000, 0x100000000, 0xffffffff00000002) ["../../../../src/kernel/bsd/sys_generic.c":2179, 0xfffffc00002b3118] 9 syscall(0x4000, 0x0, 0x0, 0x1200012fc, 0x0) ["../../../../src/kernel/arch/ alpha/syscall_trap.c":725, 0xfffffc000065f700] 10 _Xsyscall(0x8, 0x3ff800d1d18, 0x1400080b0, 0x3, 0x11fff8000) ["../../../.. /src/kernel/arch/alpha/locore.s":1814, 0xfffffc0000662edc] PROBLEM: (89964, 85632, 85344) (PATCH ID: OSF520-206) ******** This problem typically manifests itself as a kernel memory fault in bs_io_thread. The problem can be exacerbated by setting kmem_debug=0x40 and kmem_protect=4096. PROBLEM: (none) (PATCH ID: OSF520-242) ******** This patch adds code and bug fixes needed Encore Real Time Computing Inc software to run on Tru64 UNIX. PROBLEM: (91062) (PATCH ID: OSF520-320) ******** Change the rmvol error messages to more accurately reflect why rmvol failed. Change showfdmn so that it does not say it succeeded when it failed. PROBLEM: (90178, BCGM918KQ) (PATCH ID: OSF520-188) ******** Fix potential CFS deadlock. PROBLEM: (90185, 90558) (PATCH ID: OSF520-209) ******** A vfs bug was introduced in Compaq UNIX v5.1 which causes a directory look up problem in applications such as ssh. ssh v2.4.0 and v2.4.1 running on Compaq Tru64 UNIX V5.1 and later, user will see the problem when doing "ls" in sftp and when uploading public key using ssh-pubkeymgr. The problem results in an indefinite output display of effected commands. File systems which use the "new" directory format are impacted. These include NFSv3, autofs, dvdfs and cdfs. PROBLEM: (90733) (PATCH ID: OSF520-337) ******** This fixes SEL logging problem where panic events were logged as misc events. It also adds new event types that can be logged. PROBLEM: (90548, 89701, AT_G01933) (PATCH ID: OSF520-177) ******** This patch corrects a problem that is encountered when trying to create an Oracle database on a wildfire system that has a memoryless QBB. Without this patch, direct i/o to to an advfs file using asynchronous i/o will hang if it is completed on a memoryless QBB. 1. Error Message Creation of a Oracle (8.1.7.2) database fails when datafiles or redologfiles are created. Message: WARNING: aio_results_np timed out 1 times, waited 120 secs WARNING: aio_results_np timed out 1 times, waited 590 secs 2. Symptoms Oracle processes hang after this message. They can't be killed, system has to be rebootet. 3. Process leading to the symptom. Creation of a Oracle database. PROBLEM: (91327) (PATCH ID: OSF520-307) ******** This patch corrects problems when running the dd utility on a disk with a label. It would not return errors when expected. PROBLEM: (IT_G01812, SSRT0756U) (PATCH ID: OSF520-256) ******** 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. Compaq has corrected this potential vulnerability. PROBLEM: (91175) (PATCH ID: OSF520-330) ******** This patch fixes a situation in which a cluster running with multiple rads, some of which do not have valid and initialized paths, experiences problems with devices hanging with outstanding I/O. PROBLEM: (87654, 90761, FR_G02688) (PATCH ID: OSF520-285) ******** This patch fixes a problem that causes bugchecks from applications running decthreads. PROBLEM: (90130) (PATCH ID: OSF520-132) ******** This change is a fix for locking on retry case for multi-threaded select/poll. A panic with the following stack trace is indicative of this problem: PANIC: "thread_block: simple lock owned" panic thread_block() lock_wait lock_write solock soclose soo_close closef selscan do_scan select syscall _Xsyscall PROBLEM: (86308, BCSM3169H) (PATCH ID: OSF520-267) ******** This patch fixes a potential problem where system responsiveness may be impacted. In certain situations, this impact may prevent other processes from running for several seconds. This problem can occur during a filesystem synch when there are many filesystems where each contains several hundred thousand files. Note that AdvFS filesystems do not exhibit this problem. PROBLEM: (90127) (PATCH ID: OSF520-152) ******** This problem is manifested by a KMF in copyinstr under stress conditions in the DMAPI path kdm_k_pathtohandle. PROBLEM: (86747) (PATCH ID: OSF520-271) ******** This patch corrects a calculation which leads to less-than-optimal distribution of NFS client mountpoints in a hash table used by cluster mount logic. PROBLEM: (86764) (PATCH ID: OSF520-298) ******** The unintended auto-mounts create certain slow-downs which lengthens the boot process and which increases the liklihood of other mounts being slowed down. PROBLEM: (BCSMC22DM, TPO073157, FR_G02923, DJO333030) (PATCH ID: OSF520-297) ******** This patch corrects a problem where multi-volume AdvFS v3 domains exhibit I/O errors (not attributable to hardware). The same problem also causes a failed mkfset due to ENO_XTNTS. PROBLEM: (86332) (PATCH ID: OSF520-245) ******** Prior to this modification, storage allocation for a file opened for directIO could, depending on the write sizes requested, have large extent maps even though the disk is not fragmented. Although the file function correctly, performance is reduced by the numerous extent maps. This fix reduces the number of extent maps generated, and subsequently gives better IO performance on the resulting file. Extent maps for a file can be seen by using the showfile utility. PROBLEM: (91427) (PATCH ID: OSF520-328) ******** File permissions inherited from a default ACL may be different than expected in rare cases. Instead of rw------- permissions, core files are created with no permissions. Files and directories created on NFS clients are given the permissions from the default ACL, the permissions are not modified by the requested mode. When ACLs are enabled on the system and there is a default ACL on a directory, files and directories created in that directory should inherit the default ACL and permissions based on the rules that are discussed in detail in the Security manual. In particular, the file permissions should be based on the intersection of requested mode and the permissions from the default ACL, but not modified by the umask. The NFS protocol doesn't allow for passing the requested mode without the umask applied. Therefore, after this patch has been applied files and directories created on NFS clients will be given the permissions from the default ACL intersected with the requested permissions modified by the umask. This is the same as the pre-V5.0 behavior. PROBLEM: (EVT0496318B, 87204) (PATCH ID: OSF520-184) ******** This patch is to correct the problem where the DLI queue stalls when there is no traffic in the TCP/IP or HDLC stacks. In order to enable this fix, one needs to set the netisrwakeupthreshold = 0 as this will allow more than one netisr to be run by a user process. PROBLEM: (TKT262782) (PATCH ID: OSF520-240) ******** This patch corrects a problem whereby clocks on systems could move backwards after subsequent relocations of the root file system using cfsmgr. PROBLEM: (BCGM72B9W, BCGM713NZ) (PATCH ID: OSF520-262) ******** Two problems are corrected for non-NUMA systems: 1. A kernel stack not valid halt on a cpu, which will trigger a "PANIC TB_SHOOT ACK TIMEOUT" or lock timeout. From /var/adm/messages ---------------------- Jul 24 05:49:32 drpesdb02 vmunix: pmap_update_send: missing ack from cpu 9 Jul 24 05:49:32 drpesdb02 vmunix: panic (cpu 0): tb_shoot ack timeout REVISION: 2.2 DUMPFILE: vmzcore.7 NAMELIST: vmunix.7 NOTE: compressed dumpfile NOTE: kmem_debug 0x26 NOTE: CPU 9 has a haltcode of 2: kernel stack not valid PANIC: "tb_shoot ack timeout" CPUS: 10 VERSION: V5.1 (Rev. 732) MACHINE: Compaq AlphaServer GS140 6/700 2. A simple lock timeout, or a panic due to holding a simple lock during a context switch. 0 thread_block 1 lock_wait 2 lock_read 3 k_map_fault 4 vm_fault 5 trap 6 _XentMM 7 pmap_dup 8 vm_dup_va 9 aio_init 10 syscall 11 _Xsyscall PROBLEM: (85560, FR_G01693, HPAQ11R1R, SC45-0500) (PATCH ID: OSF520-180) ******** This patch corrects an issue seen on NFS clients. The aggressive behaviour of client negative lookup cache for concurrent create/lookup was tamed. PROBLEM: (BCGM21ZXL, 86314, BCGMB0PS8) (PATCH ID: OSF520-190) ******** This patch corrects an issue with mmap()ed files on a NFS mounted filesystem. Changes to a mmap()ed file were not being immediately seen. PROBLEM: (90599) (PATCH ID: OSF520-259) ******** This patch fixes a problem where the tape changer is only accessible from member that's the drd server for the changer. PROBLEM: (MXOM80005) (PATCH ID: OSF520-356) ******** This patch fixes a problem where socket based applications can hang in soclose() PROBLEM: (MGO94097A) (PATCH ID: OSF520-157) ******** During Filesystem relocation the system may panic due to a kernel memory fault when a directory larger than 8192 bytes has been deleted while simultaneously being accessed by another thread. PROBLEM: (89494, 89457, 89699, BCGM8198G) (PATCH ID: OSF520-198) ******** This patch corrects a kernel memory fault on multiple cpu systems when two or more cpus find an AdvFS problem at the same time. PROBLEM: (85887) (PATCH ID: OSF520-258) ******** Problem Description: This patch addresses a fix that is required if a system crashes while a volume is being removed from one of the AdvFS domains. If that crash occurs while a specific portion of code is being executed, the subsequent recovery of that domain will fail. This patch removes that window. The resulting domain panic will yield the following stack trace: 7 domain_panic 8 ftx_bfmeta_rec_redo 9 ftx_recovery_pass 10 ftx_bfdmn_recovery 11 bs_bfdmn_activate 12 bs_bfdmn_tbl_activate 13 bs_get_dmntbl_params 14 msfs_real_syscall 15 msfs_syscall 16 syscall PROBLEM: (HPAQ90VL6, 90457) (PATCH ID: OSF520-197) ******** This patch corrects the problem where attempts to delete psets can hang the system. PROBLEM: (90244) (PATCH ID: OSF520-315) ******** If a metadata page is about to be put onto the blocking queue, we need to first check to see if the log needs to be flushed in order to maintain the log write-ahead rule. PROBLEM: (91440) (PATCH ID: OSF520-325) ******** The corruption found was traced to error handling in certain conditions when multiple volumes are full. AdvFS would rearrange the last extent because it thought there was a hole. All cases will have a sub extent map with a hole descriptor whose page number is greater than the following extent's page number. This is not allowed under any circumstances and is a corruption of the extent map and therefore a corruption of the domain. An example you would see would look like: submap vd# Offset Cnt extentCnt bsPage vdBlk ====================================================== [11] 4 71 5 4 71 276672 72 260672 75 276960 76 -1 updateStart [12] 4 71 5 4 71 276672 72 260672 75 276960 76 -1 [13] 3 76 1 2 76 3550320 77 -1 [14] 12 77 3 3 77 -1 <--- error out of order 76 619223 79 -1 PROBLEM: (DEK063069, BE_G01725, BCSM20DQH, STL351462, BCSM20RBF, HPAQC1VVB, 91815, HPAQ12S9K, BE_G03046) (PATCH ID: OSF520-360) ******** This patch fixes a problem with multi-threaded applications that can cause the application to consume 100% of the CPU usage time. The problem is two-fold: (1) a race condition in posting and delivering signals exists and (2) nxm_idle() fails to clear a condition that keeps it from ultimately blocking as it should when invoked by an idle scheduler thread. PROBLEM: (90755) (PATCH ID: OSF520-286) ******** This patch fixes a domain panic in a cluster when a file system is mounted on a disk accessed remotely over the cluster interconnect. PROBLEM: (87371) (PATCH ID: OSF520-140) ******** This patch corrects locking problems in vclean(). PROBLEM: (90560) (PATCH ID: OSF520-266) ******** This patch fixes the CEH bus/target and lun number when lun > 127. PROBLEM: (90511) (PATCH ID: OSF520-326) ******** A kernel memory fault can occur when a device is deleted while there is outstanding IO. PROBLEM: (85196) (PATCH ID: OSF520-342) ******** This corrects problems with USB causing panics under heavily stressed systems. PROBLEM: (TKT232044) (PATCH ID: OSF520-278) ******** NetRAIN virtual interface counters are not maintained properly, which affects reporting via netstat and snmp, and affects the proper operation of NetRAIN. PROBLEM: (91393, 91102) (PATCH ID: OSF520-327) ******** This patch provides the following: - NHD4 enablers for future hardware support of an array controller - Fix to a problem found with raid services. o Applications that use Raid Services for online deletion of logical units could delete a unit that is in use. PROBLEM: (90956) (PATCH ID: OSF520-296) ******** The psrinfo -v command may print an incorrect CPU cache size in a mixed CPU size/speed environment. In addition different runs of the command may report different cache sizes for a specific CPU. PROBLEM: (GB_G02319, 90174, CFS.87260) (PATCH ID: OSF520-314) ******** This patch fixes a problem where a panic in assert_wait_mesg can occur. The problem can only occur in a cluster environment where the cluster configuration is modified (automatically or manuall) during times of excessive IO loads. PROBLEM: (SEARS-479) (PATCH ID: OSF520-166) ******** This change fixes a problem where tape and changer devices on fibre could occassionally return an incorrect offline status. This happens when there are more than 2 unit attentions presently queued up for the device. PROBLEM: (90922) (PATCH ID: OSF520-302) ******** This patch resolves the long-standing problem of saving a kernel crash dump after the disk driver shutdown code has been invoked. Previously, rather than taking a crash dump, the kernel would display the message: "DUMP: crash dump skipped: 'dont_dump' enabled." With this patch, a crash dump to memory is attempted. Additionally, it may be possible to write crash dumps to disk even after driver shutdown. This worked in limited testing (and may become commonplace). For now, to enable this, enter the following commands (as root) after boot: # dbx -k /vmunix /dev/mem (dbx) assign dump_usedowndisk=1 (dbx) quit PROBLEM: (90937) (PATCH ID: OSF520-202) ******** This patch fixes a potential race condition in the Virtual Memory subsystem. There is code in the vm_page_clean() routine that modifies a vm_page pg_busy and pg_reserved fields without the page lock being held. This might lead to potential vm_page list corruption in the kernel. This patch corrects the code to properly modify those fields while the vm_page lock is held. PROBLEM: (90985, 90394) (PATCH ID: OSF520-310) ******** This patch adds support for DS25 This will also fix a minor bug in the ES45 environmental error handling code. This bug may cause an incorrect print out on a 680 environmental machine check. This does not effect the data written to the binary log. PROBLEM: (86377, 87380, 90190, TKTB30117, BCGM40Z3J, TKT216655, SE_G02157) (PATCH ID: OSF520-263) ******** This patch corrects problems with NFS server V3 and AdvFS. Specifically NFS V3 can use large buffers and without this correction hangs could occur. Additionally, AdvFS could return EIO errors under certain conditions which have been fixed with this patch. PROBLEM: (BCGM51RKR) (PATCH ID: OSF520-264) ******** This addresses a kernel memory fault panic in malloc_thread(). panic() trap() _XentMM() malloc_thread() PROBLEM: () (PATCH ID: OSF520-257) ******** This patch fixes the predictable TCP Sequence Number. PROBLEM: (91142) (PATCH ID: OSF520-319) ******** This fix addresses a data inconsistency that can occur when a CFS client reads a file that was recently written to. Stale data can be returned to the client. PROBLEM: (90070) (PATCH ID: OSF520-311) ******** This patch is in support of a cluster patch. PROBLEM: (90736) (PATCH ID: OSF520-253) ******** This problem manifests itself as a deadlock between thawfs and addvol (or rmvol). If multiple domains are frozen, an addvol (or rmvol) on one of the domains (domain 1) will hang until the domain thaws. If a thawfs is run on on the other domain (domain 2), it will hang waiting for a resource that is being held by the addvol (or rmvol). Once that thawfs hangs, it blocks all subsequent thawfs's and deadlock occurs. PROBLEM: (87391, 89027, 84361, 89376, 89775) (PATCH ID: OSF520-323) ******** This patch fixes the following problems: - KMF while unmounting cfs file system - panic with "simple lock: minumum_spl violation" - panic with "simple lock: time limit exceeded" in "spec_reclaim" - specalias structures not being freed - mount command with the extend -u option caused panic PROBLEM: (90245, 90054) (PATCH ID: OSF520-329) ******** Attempting to modify the MTU of a lag interface (for example: ifconfig lag0 ipmtu 1000) would modify the MTUs of the attached ports, but would not modify the MTU of the lag interface itself. As a result, link aggregation would not work with gigabit ethernet jumbo frames, nor did it work properly if the MTU was decreased below 1500. If a port was down when it was enabled for link aggregation, LAG would attempt to use it anyway, resulting in lost packets and inability to communicate. The load distribution algorithm used by link aggregation resulted in poor performance in server-to-server configurations (for example: one link receives all the traffic, while other links are idle). PROBLEM: (90640) (PATCH ID: OSF520-287) ******** This patch fixes a situation where a failed open to a device will cause an error that the device cannot be deleted using hwmgr. The following is an example of how to reproduce the problem: Physically remove a disk like dsk2 hwmgr -scan scsi hwmgr -show scsi (there should be no path to dsk2) disklabel -r dsk2 (forces an open to the device, should get no such device error) hwmgr -delete scsi -did 2 (did for dsk2, should get an error here) This patch will allow the hwmgr -delete command above to complete successfully. PROBLEM: (91113) (PATCH ID: OSF520-238) ******** An incorrect return type in a logging routine prevented proper operation of the memory troller on a DS20L. This patch fixes the return type PROBLEM: (90376) (PATCH ID: OSF520-145) ******** In rare cases, when off-lining a CPU the kernel may panic as follows panic:lock_done: lock not owned by thread A stack trace of the resultant crashdump will appear as follows (editted for brevity):(dbx) t > 0 stop_secondary_cpu() "src/kernel/arch/alpha/cpu.c":1343 1 panic() "src/kernel/bsd/subr_prf.c":1296 2 event_timeout() "src/kernel/arch/alpha/cpu.c":2206 3 printf() "src/kernel/bsd/subr_prf.c":981 4 panic() "src/kernel/bsd/subr_prf.c":1353 5 lock_fault() "src/kernel/kern/lock.c":2765 6 lock_done() "src/kernel/kern/lock.c":1027 7 mapped_alloc() "src/kernel/bsd/kern_malloc.c":4605 8 malloc_internal() "src/kernel/bsd/kern_malloc.c":1677 9 _evmmiscRealloc() "src/kernel/kevm/evmmisc.c ":429 10 _evmuiAllocateEvent() "src/kernel/kevm/evmcreate.c":352 11 EvmItemSetVa() "src/kernel/kevm/evmitem.c":686 12 EvmVarSet() "src/kernel/kevm/evmvar.c":346 13 hwc_post_state_chg_event() "src/kernel/io/common/hwc/hwc_events.c":1024 14 hwc_set_access_state() "src/kernel/io/common/hwc/hwc_common.c":1866 15 ehm_cpu_offline() "src/kernel/arch/alpha/hal/platform_switch.c":1609 16 halt_secondary() "src/kernel/arch/alpha/cpu.c":1430 17 idle_thread() "src/kernel/kern/sched_prim.c":4598 (dbx) This problem has rarely been seen and can not be reliably reproduced. PROBLEM: (90914) (PATCH ID: OSF520-231) ******** The vdf and showfdmn commands might incorrectly claim that you have the error showfdmn: No such file or directory This will occur when, for example, you create a domain with two volumes. Now you remove the initial volume, When you issue either the vdf or "showfdmn -mk" commands, the error will appear. PROBLEM: (AT_G02174, 90034) (PATCH ID: OSF520-265) ******** This problem causes ADVFS to access kernel memory which has been freed. If that memory was reallocated to another subsystem, the panic may occur in a subsystem other than ADVFS. This problem will usually result in the message: PANIC: 'kernel memory fault' A typical ADVFS stack trace is: 4 panic src/kernel/bsd/subr_prf.c : 1309 5 trap src/kernel/arch/alpha/trap.c : 2262 6 _XentMM src/kernel/arch/alpha/locore.s : 2115 7 advfs_ubc_page_hold src/kernel/vfs/vfs_ubc.c : 2987 8 advfs_page_hold src/kernel/msfs/bs/bs_buffer2.c : 2071 9 bfflush_start src/kernel/msfs/bs/bs_qio.c : 3746 10 bs_bf_flush_nowait src/kernel/msfs/bs/bs_qio.c : 4395 11 cp_copy_page_range src/kernel/msfs/bs/bs_copy.c : 309 12 migrate_normal src/kernel/msfs/bs/bs_migrate.c : 1648 13 migrate_normal_one_disk src/kernel/msfs/bs/bs_migrate.c : 1275 14 mig_migrate src/kernel/msfs/bs/bs_migrate.c : 1050 15 bs_migrate src/kernel/msfs/bs/bs_migrate.c : 933 16 msfs_syscall_op_migrate src/kernel/msfs/bs/bs_misc.c : 5749 17 msfs_real_syscall src/kernel/msfs/bs/bs_misc.c : 3637 18 msfs_syscall src/kernel/msfs/osf/msfs_syscalls.c : 145 PROBLEM: (88138, 87569, 87369, 86825, 87636, 88029, 89152, 89464, 89563, 89575, 89603, 89732, 89801, 89804, 90757) (PATCH ID: OSF520-334) ******** PROBLEM: (86825, 87569, 88138, 89603 and 89732) (PATCH ID: ) Application and system hangs may occur when I/O fails to abort. PROBLEM: (87369) (PATCH ID: ) The KZPEA driver failed to clear pending I/O when a 3rd party bus reset or hardware requested initialization occurred. PROBLEM: (88029, 89152, 89801 and 89804) (PATCH ID: ) Open errors may occur when attempting to open a device connected to the KZPEA during a bus or device reset. PROBLEM: (89464, 89563, 89575 and 89763) (PATCH ID: ) A "Kenerl Memory Fault" panic could occur due to a timing window where an aborted I/O could be sent to the device while the I/Os resources were released. Depending on the timing the resulting panic trace could be one of the following: Trace #1 > 0 boot src/kernel/arch/alpha/machdep.c : 2774 1 panic src/kernel/bsd/subr_prf.c : 1255 2 lock_fault src/kernel/kern/lock.c : 2745 3 lock_write src/kernel/kern/lock.c : 899 4 lgr_flush_start src/kernel/msfs/bs/ms_logger.c : 4326 5 msfs_mntflushbuf src/kernel/msfs/osf/msfs_vfsops.c : 4851 6 mntflushbuf src/kernel/vfs/vfs_bio.c : 1877 7 boot src/kernel/arch/alpha/machdep.c : 2685 8 panic src/kernel/bsd/subr_prf.c : 1334 9 lock_fault src/kernel/kern/lock.c : 2745 10 lock_read src/kernel/kern/lock.c : 1239 11 k_map_fault src/kernel/vm/vm_kmap.c : 426 12 vm_fault src/kernel/vm/vm_fault.c : 168 13 trap src/kernel/arch/alpha/trap.c : 2137 14 _XentMM src/kernel/arch/alpha/locore.s : 2115 15 SCSIhAbortTask src/kernel/io/cam/aha_chim/chim/src/hwmtask.c : 1308 16 SCSIHQueueSpecialHIOB src/kernel/io/cam/aha_chim/chim/src/hwmtask.c : 265 17 SCSIrAbortTask src/kernel/io/cam/aha_chim/chim/src/rsmtask.c : 1112 18 SCSIRQueueSpecialHIOB src/kernel/io/cam/aha_chim/chim/src/rsmtask.c : 175 19 SCSIQueueIOB src/kernel/io/cam/aha_chim/chim/src/xlmtask.c : 3946 20 EnqueueAdapterOsmIOB src/kernel/io/cam/aha_chim/aha_chim_if.c : 1931 21 aha_chim_abort_job src/kernel/io/cam/aha_chim/aha_chim.c : 2770 22 aha_chim_job_timeout src/kernel/io/cam/aha_chim/aha_chim.c : 2519 23 softclock_scan src/kernel/bsd/kern_clock.c : 1681 Trace #2 > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1343 1 panic src/kernel/bsd/subr_prf.c : 1296 2 event_timeout src/kernel/arch/alpha/cpu.c : 2206 3 printf src/kernel/bsd/subr_prf.c : 981 4 panic src/kernel/bsd/subr_prf.c : 1353 5 xpt_callback src/kernel/io/cam/xpt.c : 3702 6 aha_chim_cam_sio_done src/kernel/io/cam/aha_chim/aha_chim_scsi.c : 2877 7 NormalPostRoutine src/kernel/io/cam/aha_chim/aha_chim_if.c : 2578 8 SCSIBackEndISR src/kernel/io/cam/aha_chim/chim/src/xlmtask.c : 5345 9 OSMBackEndIntHandler src/kernel/io/cam/aha_chim/aha_chim_if.c : 2440 10 aha_chim_intr_deferred src/kernel/io/cam/aha_chim/aha_chim.c : 2452 11 aha_chim_interrupt_thread src/kernel/io/cam/aha_chim/aha_chim.c : 2350 PROBLEM: (SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-338) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (92854) (PATCH ID: OSF520-418) ******** Fixes the no-roll undo of the evm related version switched patch. When deleting the evm version switched patch. The following error message can occur if this patch was not installed: Failure to switch versions because the new version is older than than the active version PROBLEM: (91034) (PATCH ID: OSF520-501) ******** This patch fixes a problem with the logging of MUNSA reject status messages to the console during boot which could cause a system to boot extremely slow. This is a sample of what the messages could look like: 21:45:06 cam_logger: SCSI event packet 21:45:06 cam_logger: hardware_idA9 bus 23 target 17 lun 2 21:45:06 cdisk_op_spin 21:45:06 Device Not Ready 21:45:06 Hard Error Detected 21:45:06 Hardware ID = 419 21:45:06 DEC HSG80 V86F 21:45:06 Active CCB at time of error 21:45:06 Unknown CAM Status 21:45:14 cam_logger: SCSI event packet 21:45:14 cam_logger: hardware_idH3 bus 23 target 29 lun 2 21:45:14 cdisk_op_spin 21:45:14 Device Not Ready 21:45:14 Hard Error Detected 21:45:14 Hardware ID = 483 21:45:14 DEC HSG80 V86F 21:45:14 Active CCB at time of error 21:45:14 Unknown CAM Status 21:45:22 cam_logger: SCSI event packet 21:45:22 cam_logger: hardware_idB0 bus 22 target 17 lun 3 21:45:22 cdisk_op_spin 21:45:22 Device Not Ready 21:45:22 Hard Error Detected 21:45:22 Hardware ID = 420 21:45:22 DEC HSG80 V86F 21:45:23 Active CCB at time of error 21:45:23 Unknown CAM Status 21:45:31 cam_logger: SCSI event packet 21:45:31 cam_logger: hardware_idB5 bus 22 target 17 lun 1 21:45:31 cdisk_op_spin 21:45:31 Device Not Ready PROBLEM: (89250) (PATCH ID: OSF520-102) ******** This patch fixes a kernel memory fault from sth_close_fifo() caused by a NULL pointer. A typical stack trace will be; _XentMM sth_close_fifo vn_close closef close syscall _Xsyscall PROBLEM: (91602, 92396) (PATCH ID: OSF520-407) ******** The cdfs file system, based upon ISO9660 format, limited the size of the file system to 2.1GB which is less than the available space offered by DVD media formatted for ISO9660. This patch allows access to the full capacity of DVD media when utilizing an ISO9660 formatted file system on it. PROBLEM: (91549, 89848, 91409, 91310, BCGMC0ZM9) (PATCH ID: OSF520-378) ******** Cluster unlinked files were not being handled properly during a relocation. For example, applications using temporary files in /tmp could encounter problems when / is relocated from the node running the application. Such problems were due to lack of flushing of dirty buffers on the server for the unlinked files prior to relocation. Compaq has corrected this problem. PROBLEM: (88157, 88734, 90730, 76838, 80946) (PATCH ID: OSF520-487) ******** This fixes a deadlock problem when attempting to delete devices while the system disk is in error recovery. The kernel footprint will show the following traces in one or more threads: THREAD: fffffc00f7a1dc00 0 thread_block 1 sleep_prim 2 mpsleep 3 ccfg_edtscan <<< Waiting for EDT_INDELETE to clear. 4 ccfg_action 5 xpt_action 6 ccmn_scan_lun3 7 ccmn_path_ping3 8 ccmn_resolve_paths3 9 cdisk_rec_tur 10 cdisk_recovery 11 cdisk_recovery_thread PROBLEM: (92131) (PATCH ID: OSF520-385) ******** Before V5.1, if a directory permission is set to 000, we cannot stat "." entry. Assume non-superuser and /tmp/no.access.dir set to 000 permission. % stat /tmp/no.access.dir/. /tmp/no.access.dir/.: permission denied And this is a correct POSIX behavior. However since V5.1, the behavior has changed. % stat /tmp/no.access.dir/. 000 /tmp/no.access.dir This fix recovers old and correct POSIX semantics for accessing "." entry. PROBLEM: (92879) (PATCH ID: OSF520-478) ******** There is a race condition between UFS and VFS layer in which ufs_sync_int() tries to access a field in a vnode that is currently being freed due to lack of synchronization between the code paths. This results in a lock_read: simple lock owned panic within ufs_sync_int(). lock_read: simple lock owned pc of caller: 0xffffffff0043bbfc lock address: 0xfffffc001fe26078 lock info addr: 0xfffffc0001578770 lock class name: vm_kmap.vm_lock pcb slock count: 3 current spl level: 0 simple locks held by cpu 0: 0xfffffc0c0c2c30c0: 0x8000028b00020007 (cpu=0,pc=?,busy) 0xfffffc0c0b25c480: 0xc00001160000000f (cpu=0,pc=?,busy) panic (cpu 0): lock_read: simple lock owned syncing disks... crash> t (dbx) t > 0 boot 1 panic 2 lock_fault 3 lock_read 4 k_map_fault 5 vm_fault 6 trap 7 _XentMM 8 ufs_sync_int 9 smoothsync_thread() PROBLEM: (92172, 91908, 117-1-20010, BE_G03561) (PATCH ID: OSF520-429) ******** A performance regression with 2-level threads scheduling was seen. PROBLEM: (86993) (PATCH ID: OSF520-369) ******** We modified the vflushbuf algorithm, which is used to flush metadata buffers. Previously, pushing the metadata buffers was distributed throughout the smoothsync period. At low loads, however, this could result in a small number of I/O's to disk per second, which could cause the disk to "tick". This change introduces a low-water mark. When the # of dirty metadata buffers is under this threshold, some minimum number of buffers will get pushed together. No behavior change when above the threshold. Both the threshold and the minimum # of buffers are hidden sysconfig tunable variables. PROBLEM: (92747) (PATCH ID: OSF520-464) ******** This problem only occurs if the NFS server is running with the Property List Daemon enabled and the NFS client mounts the NFS filesystem using the -o proplist option. In this case, after a file has been accessed from the NFS client the disk space is not freed when the file is deleted. PROBLEM: (GB_G03575, 89303) (PATCH ID: OSF520-432) ******** System crashes with a kernel memory fault in u_seg_global_destroy. PROBLEM: (BCSM81VX7, GB_G01823, 89491) (PATCH ID: OSF520-358) ******** This fixes an invalid pointer access panic in AdvFS. This happens after AdvFS has encountered various I/O errors that cause AdvFS to put a filesystem into its domain panic state. AdvFS error handling was not properly initializing a fileset pointer variable to NULL. During cleanup, the non-null variable would falsely indicate a filesystem fileset needed to be closed and would panic due to a bad fileset pointer. PROBLEM: (QAR91602, QAR92396) (PATCH ID: OSF520-401) ******** The cdfs file system, based upon ISO9660 format, limited the size of the file system to 2.1GB which is less than the available space offered by DVD media formatted for ISO9660. This patch allows access to the full capacity of DVD media when utilizing an ISO9660 formatted file system on it. PROBLEM: (92401) (PATCH ID: OSF520-414) ******** In systems configured with a very recent version of a tape backup utility such as Legato Networker or Veritas NetBackup, if a path to the tape devices fails, the application may not be able to recover properly. PROBLEM: (91615) (PATCH ID: OSF520-347) ******** This fix corrects an ordering problem in the error path of advfs_mount that could cause a NULL pointer to be accessed. It was discovered during internal testing - "SMP Assertion failed". Code is reordered so that internal data structures are moved to a free list before the structure is realeased. This will prevent the NULL pointer and the resulting panic. PROBLEM: (91034, 90366) (PATCH ID: OSF520-502) ******** This patch fixes a problem with the logging of MUNSA reject status messages to the console during boot which could cause a system to boot extremely slow. It also corrects a problem with reservation conflicts in the TUR tecovery loops. This is a sample of what the messages could look like: 21:45:06 cam_logger: SCSI event packet 21:45:06 cam_logger: hardware_idA9 bus 23 target 17 lun 2 21:45:06 cdisk_op_spin 21:45:06 Device Not Ready 21:45:06 Hard Error Detected 21:45:06 Hardware ID = 419 21:45:06 DEC HSG80 V86F 21:45:06 Active CCB at time of error 21:45:06 Unknown CAM Status 21:45:14 cam_logger: SCSI event packet 21:45:14 cam_logger: hardware_idH3 bus 23 target 29 lun 2 21:45:14 cdisk_op_spin 21:45:14 Device Not Ready 21:45:14 Hard Error Detected 21:45:14 Hardware ID = 483 21:45:14 DEC HSG80 V86F 21:45:14 Active CCB at time of error 21:45:14 Unknown CAM Status 21:45:22 cam_logger: SCSI event packet 21:45:22 cam_logger: hardware_idB0 bus 22 target 17 lun 3 21:45:22 cdisk_op_spin 21:45:22 Device Not Ready 21:45:22 Hard Error Detected 21:45:22 Hardware ID = 420 21:45:22 DEC HSG80 V86F 21:45:23 Active CCB at time of error 21:45:23 Unknown CAM Status 21:45:31 cam_logger: SCSI event packet 21:45:31 cam_logger: hardware_idB5 bus 22 target 17 lun 1 21:45:31 cdisk_op_spin 21:45:31 Device Not Ready PROBLEM: (HPAQ12300, HPAQ318TZ, 85710, 92696) (PATCH ID: OSF520-468) ******** This patch fixes two different problems that can cause Tru64 NFS clients to panic with kernel memory faults. In both cases bad data from third party NFS servers cause the TRU64 NFS client to fail. Stack traces for the two panics: . . . 5: panic("kernel memory fault") 6: _XentMM+84: trap 7: nfs_getpage+8: _XentMM() 8: rwvp_cache+148: nfs_getpage(???, ???, 0x79a) 9: rwvp+520: rwvp_cache 10: nfs_rdwr+152: rwvp 11: vn_write+608: nfs_rdwr 12: rwuio+212: vn_write 13: write+80: rwuio 14: syscall+592: write() 15: _Xsyscall+92: syscall(0x0) And: > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1205 1 panic src/kernel/bsd/subr_prf.c : 1252 2 event_timeout src/kernel/arch/alpha/cpu.c : 1971 3 printf src/kernel/bsd/subr_prf.c : 940 4 panic src/kernel/bsd/subr_prf.c : 1309 5 trap src/kernel/arch/alpha/trap.c : 2262 6 _XentMM src/kernel/arch/alpha/locore.s : 2115 7 fattr3_to_vattr src/kernel/nfs/nfs_client.c : 994 8 nfs3_attrcache src/kernel/nfs/nfs_client.c : 581 9 nfs3_link src/kernel/nfs/nfs3_vnodeops.c : 3350 10 link src/kernel/vfs/vfs_syscalls.c : 3588 11 syscall src/kernel/arch/alpha/syscall_trap.c : 713 12 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 PROBLEM: (FR_G03596, DK_G03587, 85043, 85680, 88962, 88967, 90177) (PATCH ID: OSF520-474) ******** System may panic with: u_anon_free: page busy and the following stack trace: 0 boot 1 panic 2 u_anon_free 3 u_anon_unmap 4 u_map_delete 5 vm_map_exit 6 exit 7 syscall 8 _Xsyscall This is due to I/O clustering leaving pages held in certain code paths. PROBLEM: (92005) (PATCH ID: OSF520-377) ******** Because error conditions are reported differently from V2 than from V1, the retry counter gets exhausted prematurely, causing user applications to fail with an I/O error. PROBLEM: (87387) (PATCH ID: OSF520-498) ******** If you send an open to a tape, e.g. through 'file' or 'dt' you may have to wait up to six minutes for the command to fail in the event that no media is present in the tape drive. PROBLEM: (85248) (PATCH ID: OSF520-341) ******** Since V51, we have NUMA aware per-processor VFS namecache, in which there is one namecache list in each processor and one global negative namecache list for namecache consistency. When a processor lookups a non-existent filename, a negative namecache entry is inserted into its processor's namecache list and the global negative namecache list. When a file is created, a new (positive) namecache entry is inserted into its own processor's namecache list and remove the corresponding negative namecache entry in the global negative namecache list to avoid namecache inconsistency throughout the system. But upon rename(), the target filename is not cache_enter()'ed (UFS and Advfs). After rename(), the system relies on a next lookup for a positive namecache addition (this removes negative namecache entry if exist). This works fine if all the lookups and renames are done on one processor. But if lookup is done on one processor (constantly inserting a negative entry) while a rename is done on anotherprocessor (not inserting any positive entry and invalidating the negative entry), both positve and negative namecache entry could exist. This, in turn, leads to a mysterious file disappearance on one processor and appearance on another processor. A simple reproducer is the following. thread A while 1 cp source junk mv junk junk2 ls -l junk2 thread B while 1 cat junk2 > /dev/null PROBLEM: (FI_G03367) (PATCH ID: OSF520-404) ******** Low UBC memory conditions cause hang in advfs PROBLEM: (90472) (PATCH ID: OSF520-410) ******** This patch corrects a problem in cluster backups of global root directories or backup of different system disks in a cluster. PROBLEM: (DE) (PATCH ID: OSF520-439) ******** This problem is an unaligned access from the kernel. The symptoms are a panic similar to the following: Unaligned kernel access va=0xfffffc0023aad1a3 pc=0xfffffc000047f460 ra=... panic (cpu 0): Unaligned kernel space access from kernel mode 0 boot src/kernel/arch/alpha/machdep.c : 2644 1 panic src/kernel/bsd/subr_prf.c : 1401 2 afault_trap src/kernel/arch/alpha/trap.c : 3089 3 _XentUna src/kernel/arch/alpha/locore.s : 2278 4 seq_search src/kernel/msfs/fs/fs_dir_lookup.c : 1685 5 msfs_lookup src/kernel/msfs/osf/msfs_lookup.c : 869 6 cfs_comm_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_server.c :2922 7 cfscall_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_vnops.c : 4958 8 cfs_lookup src/kernel/tnc_common/tnc_cfe/alpha/cfs_vnops.c : 4855 9 namei src/kernel/vfs/vfs_lookup.c : 1010 10 vn_open src/kernel/vfs/vfs_vnops.c : 783 11 copen src/kernel/vfs/vfs_syscalls.c : 3487 12 syscall src/kernel/arch/alpha/syscall_trap.c : 725 13 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 This problem may show itself from advfs routines other than seq_search. The other routines include setup_for_glom_dir_entries, idx_convert_dir, new_parent, check_path_back, and remove_dots. This problem will continue to occur with each access of the bad data from the disk. So do not remount the filesystem causing the problem unless you wish a recurrence. PROBLEM: (93623) (PATCH ID: OSF520-517) ******** There are some device driver errors that may succeed if they are retried. This change allows AdvFS to initiate a retry if one of those errors is detected. /sbin/sysconfig -r advfs AdvfsIORetryControl=nn where nn is 0-9 and modifies the number of retries AdvFS will attempt. AdvFS initiated retries are in addition to the retries that the device driver will already be doing. /sbin/sysconfig -q advfs AdvfsIORetryControl will display the current AdvFS initiated retry value. If an I/O fails and it is one of the errors that may be helped by an AdvFS initiated retry, then a message will be written to the console providing information on how to modify AdvFS I/O retry behavior, as well as the current AdvFS retry settings. PROBLEM: (91171) (PATCH ID: OSF520-363) ******** PROBLEM (91171): An internal value related to the maximum I/O size for a device was being calculated incorrectly. This has now been fixed. PROBLEM: (92975, none) (PATCH ID: OSF520-409) ******** This patch does not fix a problem. This patch adds support for the DEGXA Gigabit Ethernet device, including the ES25 onboard 10/100/1000 Ethernet port. PROBLEM: (none) (PATCH ID: OSF520-349) ******** This adds a new interface to be used by tape backup applications to reserve/release access to tape and changer devices. PROBLEM: (92422) (PATCH ID: OSF520-405) ******** - NHD4 enablers for future hardware support of an array controller - Uninitialized data could cause invalid data to be written to binary error log - Missing header definitions needed by camreport and Compaq Analyze PROBLEM: (93578) (PATCH ID: OSF520-516) ******** This patch contains a variety of domain panic fixes that better capture, explain, and handle domain panics. Included are the following changes: o possible buffer over writes of domain panic messages have been prevented. o the use of dynamic memory to form domain panic message strings has been removed. o misleading information in some domain panic strings have been fixed. o the removal of some domain panic that should not occur when memory is not available to an internal AdvFS routine. The AdvFS routine in question is bmt_put_rec() which should just return status reflecting that memory was not available. A domain panic was to harsh a behavior for not getting the requested memory. The domain is still fine. PROBLEM: (92695) (PATCH ID: OSF520-434) ******** This patch fixes a cluster-as-NFS-server chown() problem. PROBLEM: (92541) (PATCH ID: OSF520-460) ******** If an attempt is made to open a raid device that is not attached to the system, a panic will result. This could happen if a controller was attached to a system, then removed and the system rebooted. PROBLEM: (DE_G03037) (PATCH ID: OSF520-453) ******** This patch fixes a problem where cluster filesystem (CFS) I/O and AdvFS domain access causes processes to hang. Node1 Node2 ----- ----- cfsmgr -r -a SERVER=Node2 /fs cd /fs/Dir dd if=/dev/zero of=/bigfile wait a little bit... ls -l & cd /fs/Dir ls -l & before ls completes, halt node ps & - hangs ls -l & - hangs df -k & - hangs PROBLEM: (91803) (PATCH ID: OSF520-408) ******** PROBLEM: (91803) (PATCH ID:) This patch fixes problems writing to CD-R and CD-RW drives. The problem is that systems with ACER M1543C chips cannot use DMA to write to ATAPI devices, like CD-R and CD-RW drives, due to a hardware bug inside the chip. When DMA writes are attempted with this chip the user may see many "[700] SCSI event" messages because of timeout errors due to the ACER chip not responding back to the software. Programs like cdrecord will terminate with multiple errors starting with a "cdrecord: I/O error. write_g1: scsi sendcmd: cmd timeout after xxx.xxx (XX) s" error or a "write track data: error after 0 bytes" error. PROBLEM: (BCGMC1CKJ, FR_G03239) (PATCH ID: OSF520-365) ******** This correction avoids a silent infinite loop in vdump by correcting the AdvFS system call OP_GET_BKUP_XTNT_MAP. The call will now return the valid xtntCnt when it fails due to E_NOT_ENOUGH_XTNTS. PROBLEM: (93015) (PATCH ID: OSF520-471) ******** Copying a large file (about 20% of the domain size which was 160Gb) into a partially fragmented file system, caused the file to suffer extreme fragmentation (1.6 million extents). PROBLEM: (92000) (PATCH ID: OSF520-384) ******** This patch fixes a kernel panic with "bfs_alloc: kernel memory fault" The kernel panics because it is trying to use a freed domain pointer. The domain pointer, dmnP, is freed because the fileset structure that it is obtained from should have also been freed, but wasn't. It wasn't freed with bfs_dealloc because the call to bfs_dealloc from bs_bfs_close is predicated upon the state of the domain at the time. Sometimes, as in this case the state is not BFD_ACTIVATED. Even when the state is not BFD_ACTIVATED, the call to bfs_dealloc should be made. For instance, when the domain state is BFD_DEACTIVATED as is the case in this panic. PROBLEM: (THALES-594, STL160583) (PATCH ID: OSF520-450) ******** This patch corrects a problem which had resulted in broadcast or multicast packets being processed multiple times on behalf of a NetRAIN device, once for each backup interface. PROBLEM: (IT_G02713) (PATCH ID: OSF520-451) ******** This patch fixes a problem that caused the 4.3BSD socket interface to return incorrect values for IOCTL calls accessing IP alias address information. PROBLEM: (88878, 92739) (PATCH ID: OSF520-420) ******** This patch supports a cluster patch which corrects a performance issue seen when multiple threads/processes simultaneously access the same file on an SMP (>1 cpu) system. PROBLEM: (90344, 91907) (PATCH ID: OSF520-389) ******** Occasionally when entering the hwmgr -view devices command on a member in a cluster the device name would not be updated and would be listed as unknown. When adding a cdrom or floppy after boot, only a and c device special files get created. In order to make all the device special files a customer would have to enter dsfmgr -K or reboot. This no longer needs to be done by the customer. PROBLEM: (DE_G03130, 91613) (PATCH ID: OSF520-473) ******** This patch fixes heap and stack limitations in older O.S. versions required for SAP. PROBLEM: (92584) (PATCH ID: OSF520-402) ******** This patch fixes several argument mismatches that could cause a system panic. 1. fs_fsync() was specified with 5 parameters when only 4 were needed. 2. cleanup_closed_list() called fs_flush_saved_stats() with the 2nd and 3rd parameters interchanged. That could lead to a panic. This will avoid a panic "bs_access: domain different from ftx domain". 3. msf_set_proplist_int() calls check_privilege with only 1 argument. Two are expected. A panic will occur if an attempt idf made to deference the second argument. This patch also fixes an incorrect usage of thread_block. This call has been changed to a call to thread_preempt. The hang scenario is as follows: Thread A is doing an mknod() and is blocked on getting the file_lock for a directory. The lock is held by thread B in the same task which is doing an open(). Thread B is blocked in find_bfap() in an unconditional thread_block() in an attempt to give up the CPU temporarily, hoping to make progress later. However thread B never wakes up. This is because another thread C in the same task, which was doing an exec(), has suspended all the other threads in the task. Thread C is itself blocked on thread A (the mknod thread). The stack trace of the 3 threads involved in the deadlock is as follows: Thread A: -------- 1 lock_wait 2 lock_write 3 fs_create_file 4 msfs_mknod 5 mknod 6 syscall 7 _Xsyscall Thread B: -------- 1 find_bfap 2 grab_bsacc 3 bs_access_one 4 bs_access 5 fs_create_file 6 msfs_create 7 vn_open 8 copen 9 syscall 10 _Xsyscall Thread C: -------- 1 thread_dowait 2 task_dowait 3 thread_ex_check 4 execve 5 syscall 6 _Xsyscall PROBLEM: (BCGMC285H, 89884) (PATCH ID: OSF520-462) ******** This patch fixes a problem that allowed an application with superuser privileges to cause a system panic when attempting to delete a non-existent connection, i.e. when the program 'tcpkill' runs while stopping ASU. PROBLEM: (88826) (PATCH ID: OSF520-379) ******** If a threaded application is written to: 1) have the first thread start the AIO read of a file opened for directIO, and 2) have a second thread wait for the AIO read to complete, then if that read spans from the normal pages of the file into the frag portion of the file, it is possible for the application to inspect the read buffer before the frag portion of the data has been transferred. The result would apear to be data corruption even though milliseconds later the data in the buffer is correct. This symptom is dependent on system timing, and may not be noticed consistently. This fix prevents this timing dependency and assures that the data has all been transferred before the AIO read has been signalled complete. It was also possible to have an AIO read of a file opened for directIO that spans the end-of-file, and have the read report that the number of bytes requested was transferred, when in fact only the number of bytes from the offset to the end of file was transferred. This has been fixed as well. PROBLEM: (90340) (PATCH ID: OSF520-376) ******** This patch prevents a panic when more metadata file space is needed and the disk write to allocate the file space fails. The foll owing message would appear: _ftx_add_lock: bad ftx handle ... ADVFS EXCEPTION When the system needs to add more space to the metadata file, the system needs to write the changed information on disk. If the write fails, it needs to fail without a panic. This fix prevents the panic from occuring and the message from appearing. PROBLEM: (HPAQ31380) (PATCH ID: OSF520-438) ******** This change removes a restriction where dynamic VMEbus device drivers could only probe one controller per driver. Multiple controllers per driver now configure successfully. PROBLEM: (91811, 92205) (PATCH ID: OSF520-395) ******** This change fixes kernel memory faults caused by ufs_sync_int accessing an inactivated or de-allocated vnode. This change also corrects a problem with negative block number detection in ufs_stratgey. PROBLEM: (none) (PATCH ID: OSF520-428) ******** This patch provides "/dev/poll" to pseudo device driver to the kernel. This driver allows for very efficient polling of a large number of file descriptors. PROBLEM: (TKT286822, 91568) (PATCH ID: OSF520-475) ******** This patch corrects a problem that caused the RFC 2001 Fast Retransmit Algorithm within the kernel to work incorrectly. A symptom of this problem is slow FTP transfer time on lossy networks. PROBLEM: (90982, 92619, 92647, 93608) (PATCH ID: OSF520-470) ******** This patch fixes three problems with the "ee" driver for DE60x Ethernet cards. These problems affect all Tru64 systems containing DE60x network interfaces. Transmit timeout race --------------------- Occasionally a transmit timeout in the "ee" driver will cause the machine to panic due to a race condition between the transmit timeout code and the receive code. The message log will contain a transmit timeout, shortly followed by the panic: ee2: Transmit timeout (scbsts = f0006050, mask = f0000c00) trap: invalid memory read access from kernel mode faulting virtual address: 0x0000000000000010 pc of faulting instruction: 0xffffffff006d0b80 ... The stack trace will be similar to the following: > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1358 1 panic src/kernel/bsd/subr_prf.c : 1299 2 event_timeout src/kernel/arch/alpha/cpu.c : 2268 3 printf src/kernel/bsd/subr_prf.c : 984 4 panic src/kernel/bsd/subr_prf.c : 1356 5 trap src/kernel/arch/alpha/trap.c : 2278 6 _XentMM src/kernel/arch/alpha/locore.s : 2213 7 ee_add_rfd_buf_locked src/kernel/io/dec/netif/if_ee.c : 2632 8 ee_add_rfd_buf src/kernel/io/dec/netif/if_ee.c : 2522 9 ee_rint src/kernel/io/dec/netif/if_ee.c : 5718 10 ee_rx_intr_work_thread src/kernel/io/dec/netif/if_ee.c : 5439 Memory allocation error checking -------------------------------- There is no recorded instance of this occurring, but error checking was added to buffer allocation in the receive path to prevent a panic if MALLOC is unable to obtain memory. DMA resource allocation ----------------------- It is possible for the platform subsystem to return fewer DMA resources than requested if resources are running low. Previously this would potentially cause a panic since the adapter might DMA into a memory location not owned by the driver. This patch recognizes and prevents that situation in the driver. In addition to the above fixes, this patch adds a new ee subsystem attribute "link_check_interval" that allows the link state polling interval to be tuned for faster failover times when using DE60x interfaces for Link Aggregation. link_check_interval ------------------- The "ee" driver detects link state changes by periodically polling the device. Previously the polling interval was fixed at two seconds. This patch allows the polling interval to be modified by setting a new ee subsystem attribute. The new link_check_interval attribute is expressed in units of hundredths of seconds. The default value is 200 (2 seconds). The recommended minimum value is 10 (0.1 seconds). The maximum value is 1000 (10 seconds). Modifying this interval is recommended only when using DE60x devices for Link Aggregation. PROBLEM: (91548) (PATCH ID: OSF520-348) ******** Showfile shows that DMAPI regions are present on a file when they are not. This occurs if managed regions are set on a file, and then removed. Showfile still thinks that DMAPI regions are still set. PROBLEM: (86883) (PATCH ID: OSF520-353) ******** This patch supports a cluster-specific patch which fixes two problems that may occur only in a cluster. A race between file name lookup and cluster mount may result in the lookup erroneously failing. This is more likely in the presence of AutoFS. The second problem is a file system recovery during failover that deadlocks. This occurs only with an Advfs fileset mounted beneath the subdirectory of /etc/fdmns that corresponds to its domain. PROBLEM: (HPAQ326XJ, 92816) (PATCH ID: OSF520-449) ******** This patch fixes an NFS readahead performance problem where performance is degraded when reading past 2 gigabytes in a file. PROBLEM: (90796) (PATCH ID: OSF520-355) ******** PROBLEM (90796): advscan incorrectly processes concatenated options (e.g. -ar vs. -a -r). For instance, if -ar is specified, the second argument (-r) will not be processed (in this case, the recreating of domains will not be done). PROBLEM: (91808) (PATCH ID: OSF520-357) ******** There will be a lock hierarchy violation if you try to extend a file on a system that does not enough enough memory. The following hierarchy violation will be seen: lock_write: hierarchy violation pc of caller: 0xfffffc0000414ce0 lock address: 0xfffffc00057beab8 lock info addr: 0xfffffc0000dde2c0 lock class name: bfAccessT.xtntMap_lk class already locked: vdT.rbmt_mcell_lk current spl level: 0 panic (cpu 0): lock_write: hierarchy violation The solution is to take out the lock that may be needed earlier on. If we do not run out of memory, release the lock. If we do, keep the lock and prevent the lock hierarchy violation. PROBLEM: (90870) (PATCH ID: OSF520-459) ******** In a cluster environment with a high volume of I/O an application may hang while and activity on one or more drives halts. Analysis of the running system or of a forced crash dump will show in the pd_rad_data structure for the hung drive(s) that io_pending count is elevated, while io_active count is zero, and that this condition does not change over time. Also helpful in diagnosing this problem is to note that in the ccmn_specific structure for the hung drive(s) the value of pd_adjust_time will be zero, and the value for IO_cred_resv_cnt will be one. PROBLEM: (90198, 92311) (PATCH ID: OSF520-386) ******** There are two basic categories of changes: 1) Treat NO SENSE as a retryable SCSI status The HSG80 (before 8.7 firmware) would send Unit Attentions on informational events to the host. This causes the Tru64 disk driver to go into recovery, which results in significant time delays while it aborts all IO, sorts everything out, and resends all IO that was in progress. With the advent of the HSG80 8.7 firmware, the host will configure the HSG80 to send NO SENSE status instead of UA, which causes the disk driver to simply retry that one IO, resulting in significantly faster error handling and possibly preventing sending an error to the file system layer, which on occasion causes ADVFS panics. 2) Analyze NOT READY status as a possibly vendor unique improvement. The HSG/V controllers will provide a vendor unique NOT READY status to give the host a hint how long they need to recover from an error condition. The host needs to back off sending the controller more commands to give the controller time to work off it's load and regain control of itself. PROBLEM: (89465, 89744, INVALID, 90057, 90077, 90272) (PATCH ID: OSF520-312) ******** The patch updates the emx driver to v2.03 and fixes a problem which could cause an emx driver panic during adapter resets. PROBLEM: (93330) (PATCH ID: OSF520-503) ******** This patch re-enables mountd to support exports file with multiline entry using leading spaces as continued line indicator. The problem was introduced with a patch that increases support of NFS file mounting from 254 to 1024 entries. PROBLEM: (HPAQ2123N) (PATCH ID: OSF520-413) ******** This patch corrects a problem with arp messages not being sent on interface static routes. PROBLEM: (none) (PATCH ID: OSF520-524) ******** This patch provides the PCI Indictment for storage component location to diagnose a PCI adapter failure. PROBLEM: (91337, BCGM11H7B) (PATCH ID: OSF520-399) ******** A deadlock problem as well as a potential problem with incorrect or inconsistent cluster devts could occur in a cluster when removing or replacing a device. The deadlock problem results in numerous threads waiting for an event (hwc_cdt_lock_down) that is blocked by the deadlock. PROBLEM: (KAOB72090) (PATCH ID: OSF520-361) ******** Moving the power supply from one slot to another can cause a panic. PROBLEM: (92212, DEK064589) (PATCH ID: OSF520-491) ******** System panics in audit_rec_build when auditing execve with the exec_argp or exec_envp audit style enabled. PROBLEM: (87802) (PATCH ID: OSF520-406) ******** This patch addresses one problem. When the system discovers a new device,it generates a new name for it to create the device special file (dsf). The instance part, a number, can get quite large when doing many disk backups using a clone-copy-delete procedure. Since the instance is always increasing, the names quickly become hard to manage. Also, the backup program must determine the new numbers each time it runs. To fix this problem, the dsfmgr program has added a new option that will minimize (or set) the instance numbers to the lowest possible value. If your system deletes and creates a large number of devices or deletes and creates devices often, this patch will help keep the values lower. For systems that have a fixed configuration except for the backup procedure, it will mean that each new set of cloned backup devices will always have the same new names. It can simplify the backup procedure. PROBLEM: (91871, none) (PATCH ID: OSF520-513) ******** This problem will only appear if rt_preempt_opt is set to 1. Invalidating a portion of a very large file, via a call to ftruncate for example, can make the filesystem appear hung. Other programs that attempt to access that filesystem will hang until the original invalidation completes. PROBLEM: (93086) (PATCH ID: OSF520-489) ******** Multiple applications utilizing RAID Services would interfere with each other when sending maintenance commands, resulting in command failures. PROBLEM: (DE_G03219, ZPOAI8823, 90872) (PATCH ID: OSF520-398) ******** This patch fixes a race in the map_gh() routine that can cause kernel panics because a level 3 page table is deallocated twice. The patch prevents different threads on multiple RADs from creating multiple references to the same level 3 page table. PROBLEM: (82734, 88992, 93322, 93499) (PATCH ID: OSF520-512) ******** Problem 1: The new_wire_method problem is a conflict between light weight wiring of segmented shared memory (ssm) and direct io. The problem can manifest itself in one of two ways: - Oracle users receive "Cannot connect to Oracle" error message - System performance degrades when users try to disconnect from Oracle Problem 2: The kernel malloc problem has only be seen with the ARMTech software and the panic is due to a malloc request size of zero. Stack trace follows: 1 panic src/kernel/bsd/subr_prf.c:1299 2 event_timeout src/kernel/arch/alpha/cpu.c:2322 3 printf src/kernel/bsd/subr_prf.c:984 4 panic src/kernel/bsd/subr_prf.c:1356 5 malloc_internal src/kernel/bsd/kern_malloc.c:1602 6 arm_db_load_keys database_files.c:208 7 read_tier structure_manager.c:401 8 read_definitions structure_manager.c:235 9 arm_db_new_structure structure_manager.c:679 10 arm_db_Initialise database_manager.c:449 11 ARMTsupport_configure export/build/ARM1_0-T64-Release1_0/ARMTech/src/ arch/Tru64/kern/common/support_module.c:239 12 subsys_conf src/kernel/bsd/subsys_conf.c:2529 13 kmodcall src/kernel/bsd/kern_kmodcall.c:317 14 syscall src/kernel/arch/alpha/syscall_trap.c:725 15 _Xsyscall src/kernel/arch/alpha/locore.s:1870 PROBLEM: (92032, 92880) (PATCH ID: OSF520-525) ******** This patch addresses an issue with regards to creation of a crashdump on certain systems that use granularity hinted regions. There is a chance that some information may be left out of that crashdump. PROBLEM: (74519, 86098) (PATCH ID: OSF520-448) ******** Increase a number of filesystems that can be mounted from 256 to 1024. It also fixes audit to generate exportfs_create audit records correctly. PROBLEM: (92498) (PATCH ID: OSF520-390) ******** This patch prevents a situation in which the disk drives on a DS25 overheat if the system door is removed for too long. With the system door removed on a DS25 there is insufficient air flow in the disk drive area for proper cooling. If the door remains off for an extended period of time the disk drives may overheat resulting in possible data loss. PROBLEM: (82981) (PATCH ID: OSF520-344) ******** In irefresh the MOUNT_VLIST_LOCK is dropped when calling vgone and iget. The mounted vnode list could change during this time and the pointer to the next vnode could become invalid causing a Kernel Memory Fault panic. PROBLEM: (92479, BCGM30G4Q) (PATCH ID: OSF520-411) ******** "An "mcs_lock: lock aready owned by cpu" system panic occurs against | task-lock for applications that directly call nxm_get_bindings. An example stack trace may be: 4 panic 5 simple_lock_fault 6 mcs_lock_state_violation 7 task_hold 8 thread_ex_check 9 sigexit 10 psig 11 trap 12 _XentMM PROBLEM: (85456, EVT43187A) (PATCH ID: OSF520-440) ******** This patch allows users other than root to now mount CDROM media on directories that they own when CDFS is statically built into the kernel. Without this patch a normal user will receive an insufficient privilege error such the following until the superuser specifically configures cdfs. $ mount -t cdfs /dev/disk/cdrom0c cdrom_test mount: super user privileges required to load cdfs module This error was due to the CDFS module being loaded on boot up but not configured. This patch fixes that issue. PROBLEM: (93376) (PATCH ID: OSF520-499) ******** When a file is opened for directIO, and there are several concurrent writers to the same AdvFS page (writes must be < 8k in size or not page-aligned), and the underlying AdvFS page is already in the UBC cache, the updates are not correctly serialized and one or more of the updates may be lost. This patch fixes this condition. PROBLEM: (none, wc.symlink.003.sec_tunables) (PATCH ID: OSF520-455) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (93019, 117-1-20278:, (N/, appears, but) (PATCH ID: OSF520-472) ******** If a MAC address is not specified when a LAG interface is created, the LAG interface would adopt the MAC address of the first port that attached to it. If that port went down, the LAG interface would switch its MAC address, and the MAC addresses of any other attached ports, to the MAC address of one of the remaining attached ports. This behavior could interact negatively with the cluster alias proxy-arp master feature, rendering the cluster alias unreachable. This patch modifies the LAG subsystem to stabilize the MAC address of LAG interfaces, by not changing the MAC address when the port from which it was derived goes down. PROBLEM: (91773) (PATCH ID: OSF520-383) ******** Fix for internal kernel panic "get_xm_page_range_info:kernel memory fault" This kernel panic occurs infrequently when one thread is adding storage to a file and another thread is actively migrating the same file. If the file appending the storage encounters an error of no more blocks (file system full) any partial storage added is removed and the in memory extent map is set to null. When the migrate thread encounters this extent map null condition, it expects the extent map to not be null and panics. PROBLEM: (BCGM111B6) (PATCH ID: OSF520-403) ******** This addresses a problem with user stack growth that could lead to crashes with multiple footprints. Known footprints include: u_anon_free: page busy percpu malloc: corrupted link (various sized buckets) vm_anon_page_alloc: APA_WAIT: page already allocated" kernel memory fault (various sized buckets) PROBLEM: (HPAQ20H9Q) (PATCH ID: OSF520-371) ******** This fix corrects a problem where df was showing negative values for large nfs filesystems. PROBLEM: (HPAQA29D5) (PATCH ID: OSF520-373) ******** Threaded realtime applications which create system contention scope threads may block indefinitely in pthread_cond_timedwait() calls if the priority of a given user thread exceeds that of the manager thread. The manager thread is a kernel thread created by the threads library to provide support for timed condition waits as well as other library support functions. If the kernel fails to elevate the priority of the manager thread to at least that of the highest priority user thread, its execution can be indefinitely postponed thereby prohibiting it from notifying the library scheduler that timeouts have expired. The run-time manifestation can be performance degradation or process hangs. PROBLEM: (93070) (PATCH ID: OSF520-469) ******** The current maximum for the ufs subsystem's inode_hash_size attribute is too low for the current generation of very large memory systems. This patch enables larger settings, which are more appropriate for these systems. For example, SpecSFS (NFS) performance can be significantly lower without this fix. The original maximum value (16K) seriously limits the filesystem's capability. By maximizing the value, significant increases in SpecSFS performance have been observed. PROBLEM: (HPAQ329B2) (PATCH ID: OSF520-452) ******** This patch fixes a problem that was causing the tcp_rad_fasttimo timer to consume excessive amounts of CPU time. PROBLEM: (93811) (PATCH ID: OSF520-535) ******** When mounting an AdvFS filesystem with the -o dual option in a cluster, the domain Id was not always being updated. If the mount -o dual happened on a node other than the node that was serving the original domain, AdvFS did not detect that the domain Id was already active and failed to update the Id for the new domain. The fix is to always create a new domain Id when the -o dual option is used. The effects of this problem include incorrect behaviour of some AdvFS commands including the showfdmn utility. PROBLEM: (SE_G04310) (PATCH ID: OSF520-555) ******** This patch corrects a problem introduced in a prior patch which can result in a system panic when outputting through the packet filter. PROBLEM: (91762) (PATCH ID: OSF520-520) ******** PROBLEM: system crashes after reconnecting a cable or resarting an HSZ80 with heavy I/O to it. This is seen under heavy I/O load to a disk array with multiple paths active. When a path or controller fails, the failover process succeeds and there is no problem until the path(s) are restored. Ussually, within a minute, one member in the cluster will error out its I/O to the device. Other members may start to crash shortly there after. Remove EEI_MUNSA_REEI_MUNSA_REJECT change. Correct history message. PROBLEM: (87862) (PATCH ID: OSF520-467) ******** Problem: Using LSM volumes greater than 1Tb in an AdvFS domain can cause various problems from spurious errors to possible filesystem corruption or panics. This patch fixes this problem. Problem: AdvFS cannot use volumes greater than 2Tb, even though they can be constructed with LSM. Before this fix, there was no warning if the user tried to use such a volume in an AdvFS domain. Now a warning is issued. PROBLEM: (BCPM8022Z) (PATCH ID: OSF520-684) ******** This patch fixes a problem where AdvFS domains from a pre-V5.0 system which are mounted on a V5.1A PK3 system would incorrectly give "corrupted directory entry size" error messages when some files were accessed. PROBLEM: (92041) (PATCH ID: OSF520-728) ******** Systems configured with VX1 graphics cards will not switch the graphics head display to VGA text mode. When the Xserver window system is running, VGA text display mode should be restored when the halt button is pressed. Console commands can then be echo'd to the VGA display for diagnostic purposes. Without this fix, the console commands will not be displayed. PROBLEM: (94115,, 94105,) (PATCH ID: OSF520-603) ******** This patch fixes following two problems in CAM area: 1. After a host or HSV reboot, some time IO took several minutes (upto 30) start. 2. A problem with reservation conflict when multiple paths are present. This problem was seen when a snapshot was created, but we failed to read from the snapshot. PROBLEM: (93382) (PATCH ID: OSF520-532) ******** This problem only occurs when Access Control Lists (ACLs) are enabled. It only occurs on AdvFS filesystems. If there is a Default Access ACL on a directory and a symbolic link is created in the directory the permissions on the symbolic link will appear to be the permissions from the Default Access ACL when you look at the permissions, e.g. with ls(1) or stat(2). Permissions are ignored for symbolic links, so access through the symbolic link is not affected. With this patch, new symbolic links created will show the proper permissions, rwxrwxrwx (777). PROBLEM: (94558) (PATCH ID: OSF520-694) ******** There was a race between the IO completion routine and the routine that waits for all IOs to be completed when removing a volume. Under certain conditions, the volume removal could occur before the IO completion routine was done touching the in-memory structure for the volume. This fix corrects that race. PROBLEM: (94537) (PATCH ID: OSF520-671) ******** This patch fixes a RFC conformance problem with IPv6. The problem is visible when running TAHI conformance test suite. Test #4 in the "IPv6 Specification" section fails. The cause of the failure is extra bytes sent on the network. PROBLEM: (93087, 93270) (PATCH ID: OSF520-588) ******** Prevents ICS_UNABLE_TO_MAKE_PROGRESS panics. PROBLEM: (93714, 92650, 92648, KMF, 92212, 83371, 94138) (PATCH ID: OSF520-732) ******** PROBLEM: Not all audit data in the log is displayed after being sorted. PROBLEM: System panic in audit_rec_build. PROBLEM: Setting select/deselect flag on a directory does not affect if an audit event is generated (with obj select/obj deselect) when an audited file operation is performed. PROBLEM: (STL428023) (PATCH ID: OSF520-593) ******** Do no initialize USB Hub on systems where USB is not supported. This avoids a rare KMF where the faulting virtual address and pc are : fault_va = 0x6275685f627374 = "usb_hub" fault_pc = 0x6275685f627374 = "usb_hub" PROBLEM: (93757, 93828) (PATCH ID: OSF520-556) ******** PROBLEM: mmap(0, ..., ..., MAP_FIXED|..., ..., ...) returns failure. PROBLEM: mismapped memory after a call to madvise or nmadvise with the MADV_DONTNEED flag set on an area of shared memory. This does not have a fixed symptom. PROBLEM: (none) (PATCH ID: OSF520-587) ******** This patch provides the PCI Indictment for storage component location to diagnose a PCI adapter failure. PROBLEM: (93730, SSRT0845U) (PATCH ID: OSF520-604) ******** PROBLEM: (93730 SSRT0845U SSRT0845) A potential security vulnerability has been identified in the HP Tru64 UNIX operating system which may result in non-privileged users gaining unauthorized access to files or privileged access on the system. This potential vulnerability may be in the form of a local and remote security domain risk. Cross Reference: VU#809347 The following potential security vulnerability has been corrected: o SSRT0845U stdio file descriptors (Severity - High) PROBLEM: (81512) (PATCH ID: OSF520-547) ******** This problem will only be seen if you mmap a file with the MAP_PRIVATE flag. The time that it takes for the msync system call to complete will grow exponentially with the range that is passed in. With files that are a gigabyte or more, the msync call can take several minutes to complete. This patch signifigantly decreases the amount of time that msync takes to complete. PROBLEM: (93742) (PATCH ID: OSF520-742) ******** This code enhancement improves the process exit procedure for processes that have had the "nice" command used on them PROBLEM: (94453, 94489, 94517, 94376, 94375) (PATCH ID: OSF520-702) ******** PROBLEM: qar 94453 An MFS filesystem cannot be unmounted if the mfs daemon is not present. # umount /mnt/mfs /tmp_mnt/mfs: I/O error # umount -f /mnt/mfs /mnt/mfs: I/O error PROBLEM: qar 94489 MFS can panic in unmount. # mfs -s 500 /mnt/mfs; cd /mnt/mfs # kill the MFS daemon # sleep 1; cd; umount /mnt/mfs One example of a stack trace: > 0 boot() 1 panic() 2 simple_lock_fault() 3 simple_lock_minspl_violation() 4 vfs_busy() 5 dounmount() 6 mfs_mount_block() 7 mfs_start() 8 local_mount() 9 mount1() 10 syscall() 11 _Xsyscall() PROBLEM: qar 94517 Error paths in ufs_mount can lead to panic. This is only seen if the system would fail a mount operation due to insufficient memory. PROBLEM: qar 94376 A getdirentries operation on the FDFS filesystem shows an error: # ls /dev/fd /dev/fd: Invalid argument ... PROBLEM: qar 94375 The FDFS filesystem cannot be unmounted after an attempt is made to create a file within it. # touch /dev/fd/abc touch: /dev/fd/abc cannot create # umount /dev/fd /cluster/members/member0/dev/fd: Device busy PROBLEM: (TKT299545/QAR, 92273, 93715) (PATCH ID: OSF520-599) ******** This patch eliminates a hang seen while unmounting an Advfs fileset. PROBLEM: (94454) (PATCH ID: OSF520-740) ******** This problem was introduced when a change was made to the sizing code in bl05. Not all Titan-based platforms implemented the full hardware support for 4 hoses The TS202c platform only implemented 3 out of the 4 hoses. PROBLEM: (94450, SSRT2309) (PATCH ID: OSF520-646) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the xdr library, which is used by the rpc library. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (94404) (PATCH ID: OSF520-629) ******** The symptom of this problem is a kernel memory fault, most often originating in the fault path for anonymous memory. A typical stack traceback is shown below: 0 boot src/kernel/arch/alpha/machdep.c 1 panic src/kernel/bsd/subr_prf.c 2 trap src/kernel/arch/alpha/trap.c 3 _XentMM src/kernel/arch/alpha/locore.s 4 _a_lock_C src/kernel/arch/alpha/lockprim.s 5 anon_getpage src/kernel/vm/vm_anon.c 6 u_anon_fault src/kernel/vm/u_mape_anon.c 7 u_map_fault src/kernel/vm/vm_umap.c 8 vm_fault src/kernel/vm/vm_fault.c 9 trap src/kernel/arch/alpha/trap.c 10 _XentMM src/kernel/arch/alpha/locore.s PROBLEM: (94612) (PATCH ID: OSF520-686) ******** This patch fixes a loss of single system image when a Cluster acts as an NFS client to some external NFS server. Certain error conditions may lead to some of the CFS client nodes being unable to access an NFS filesystem that is still mounted and accessible from other nodes in the cluster. The problem scenario involves a an unsuccessfull unmount attempt, an entry not found in the NFS attribute cache at the CFS server, and an error returned from the NFS server. PROBLEM: (94706) (PATCH ID: OSF520-718) ******** Under certain conditions, appending data to a file can cause the system to panic. It is known to happen when using UFS. PROBLEM: (92468, 93276, 93877, 93955) (PATCH ID: OSF520-601) ******** This patch fixes two problems and adds support for one new feature in the "ee" driver for DE60x 10/100 Ethernet adapters. These problems affect all Tru64 systems containing DE60x network interfaces. (1) A panic can occur while a system is rebooting if the "ee" driver is actively receiving data when its shutdown routine is called. This fix prevents buffers from being freed while they are still in use. (2) Occasionally a packet can stall in the send queue instead of being transmitted. It will be pushed onto the wire by the next packet that is transmitted. This fix prevents packets from stalling in the send queue. (3) This patch adds tagged ethernet frame capabilities to the "ee" driver, in support of IEEE 802.1Q (VLAN). PROBLEM: (HPAQ4221F, DSATL0V8M) (PATCH ID: OSF520-664) ******** This patch resolves kernel memory faults in soqremque(). A typical stack trace would be: soqremque tcp_close tcp_usrreq soclose soo_close closef PROBLEM: (92703) (PATCH ID: OSF520-745) ******** This change corrects two problems: Corrects insmntque() to use proper locking when inserting and removing vnodes from the mount vlist. Adds a check in shadowvode() to validate the specinfo structure pointer before using the macro to obtain the pointer to the shadow vnode. PROBLEM: (BCGMK1ZKL) (PATCH ID: OSF520-731) ******** This patch fixes a problem when the kernel incorrectly closes a socket that causes Sybase 1613 errors to be produced. PROBLEM: (94943) (PATCH ID: OSF520-779) ******** This fix allows hardware event notifications by a Smart Array controller that occur on an system that is not booted to be logged into the binary.errlog when the system is booted. This is useful in diagnosing logical volume failures should it occur. PROBLEM: (117-1-20845) (PATCH ID: OSF520-705) ******** This patch fixes a problem in which fuser is unable to report on all referenced resources. This is a problem when attempting to identify reasons for unmount failures. PROBLEM: (BCGM80033, 93793, 93783) (PATCH ID: OSF520-722) ******** Processes accessing an NFS mount hang and go uniterruptible. The server is still accessible, as other mounts from the same server still respond. Other clients can access the same mount. This is due to an orphaned mbuf being tied up and hanging the NFS thread. PROBLEM: (92897) (PATCH ID: OSF520-500) ******** This patch addresses the handling of lock acquisition and release ordering when erasing device mapping contained within SCSI_DIDs. PROBLEM: (93560) (PATCH ID: OSF520-533) ******** This patch fixes a problem with printing long double values. In some cases, when printing long double values using the %Lf format, an internal buffer overflows and produces a seg fault. The buffer allocation has been changed to ensure sufficient space for long doubles. PROBLEM: (94513) (PATCH ID: OSF520-695) ******** When using mcs locks, the problem is a panic, "mcs_unlock: current lock not found" occurs, with stack trace: panic simple_lock_fault mcs_unlock_found_violation get_pshared_object nxm_pshared_init _Xsyscall When not using mcs locks, the problem would be a memory discrepancy and subsequent kernel memory fault. PROBLEM: (83691, 92049, 93234, 94098, 94151, 86744, 88241) (PATCH ID: OSF520-638) ******** This patch includes a number of fixes to problems in the io/cam space. PROBLEM: (ZPO148195) (PATCH ID: OSF520-678) ******** This patch adds code to print greater than 61 UNIX domain sockets & change file read errors from /dev/kmem to ignore and continue in a running system. PROBLEM: (93003) (PATCH ID: OSF520-536) ******** This patch alleviates a temporary hang/pause condition seen when forking or running down an application with several child processes, from a parent process having an extremely large number of unique or discontigous memory allocations. The temporary hang/pause occurs during the forking or run-down of child processes belonging to a parent process with an extremely large number of map entries (>30000). The hang is the result of having to inherit or remove the extensive list of map entires to or from the child process while other activity is taking place against the process address space. The hang/pause condition is only temporary and should eventually make forward progress. The length of the hang is related to the number of map entries the parent process has and the number of child processes involved. The larger the number of map entries and the more child processes involved, the longer the hang. Map entries are descriptors that describe the various parts of a processes address space. A map entry is created for each unique or non-adjacent address space that is created. Depending on which CPU the forking or exitting process is running on, the hang may cause telnet or ping requests to also hang temporarily. PROBLEM: (94359) (PATCH ID: OSF520-608) ******** This patch fixes a problem in the strncpy routine which erroneously writes outside the buffer that was passed into strncpy. The problem occurs when the size passed in is a multiple of 8, and the trailing NULL which terminates the source string is written to the last byte of the specified buffer. In this case, the strlen routine will load the quadword following the specified buffer, make no modifications to it and store it back to memory. If another thread stores a different value to that quadword between the erroneous load and store, the other thread's value will be lost. After this patch is applied, strncpy correctly detects that it is done, and doesn't touch the following quadword. PROBLEM: (TKT336480) (PATCH ID: OSF520-673) ******** This patch resolves kernel memory faults in sonewsocknolock(). A typical stack trace would be: sonewsocknolock tcp_input_common tcp_input ipintr netisr_thread PROBLEM: (91926) (PATCH ID: OSF520-628) ******** This patch fixes a bit masking error in the kernel code such that correctable error reporting will get turned back on for any CPU, not just CPU 0, when the time period to throttle the correctable errors has expired. Throttling is a mechanism in the kernel to turn off the reporting of correctable errors for a period of time, if a lot of correctable errors are getting reported within a short time frame. This prevents the error logs from getting filled up with too many correctable error messages. The problem is that once correctable errors are throttled for any CPU, except CPU 0, the reporting of the correctable errors will stay turned off indefinitely, rather than getting turned back on after the throttling time period has expired. PROBLEM: (94859, 94097) (PATCH ID: OSF520-751) ******** This patch corrects a problem found wherein the rmtmpfiles script would produce errors at startup of the form: dirclean: lstat failure for starting directory: /.osonly_tmp/: No such file or directory The same error would show up nightly from the cleanup commands in root's crontab. The CDSL and corresponding member-specific directories will now be created if necessary when the rmtmpfiles script runs. The problem corrected was inadvertently introduced in patch 807.00. PROBLEM: (92681, 94943) (PATCH ID: OSF520-795) ******** This patch fixes a possible system hang condition that could occur during Smart Array error recovery. If the configuration includes a Smart Array and a system hang occurs, apply this patch. PROBLEM: (93043) (PATCH ID: OSF520-507) ******** An earlier patch had addressed a hang caused by an incorrect usage of thread_block. This prompted AdvFS to look at all its uses of thread_block to ensure that they were being used correctly. This patch is the result of that analysis. By using an assert_wait or an assert_wait_mesg_timo, the existing thread_block calls are made safe. PROBLEM: (QAR94058, DSATL0KQN) (PATCH ID: OSF520-674) ******** This patch fixes an AdvFS asynchronous direct IO problem that could cause a thread to hang. The asynchronous IO completion handling by AdvFS did not always decrement the v_numoutput field in the vnode. When the vnode was eventually put on the free list it still had an non-zero count in v_numoutput. When another thread tried to get a new vnode, and happened upon this one, it would hang waiting for v_numoutput to go to zero during vclean(). A typical stack trace for the hung thread is: 0 thread_block() ["/kernel/kern/sched_prim.c":3284, 0xfffffc00002e72e0] 1 vflushbuf_aged() ["/kernel/vfs/vfs_bio.c":2149, 0xfffffc0000602d14] 2 vclean() ["/kernel/vfs/vfs_subr.c":3231, 0xfffffc000060ca04] 3 vgone() ["/kernel/vfs/vfs_subr.c":3496, 0xfffffc000060cdc0] 4 getnewvnode() ["/kernel/vfs/vfs_subr.c":2120, 0xfffffc000060b6cc] 5 vdealloc() ["/kernel/vfs/vfs_subr.c":1746, 0xfffffc000060af48] 6 vrele() ["/kernel/vfs/vfs_subr.c":2841, 0xfffffc000060c39c] ... PROBLEM: (89132:, 90220:, 93204:, 94076:) (PATCH ID: OSF520-717) ******** shutdown -p does not work. Bad translation of IPMI power sensor values lead to erroneous redundant power supply failure messages. IPMI sensor reads will timeout under heavy system load and are logged as 686 OS-detected environmental errors. Some 686 logout frame fields are filled incorrectly. PROBLEM: (88820) (PATCH ID: OSF520-693) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (91654, 93118) (PATCH ID: OSF520-798) ******** This patch will fix a rmvol E_PAGE_NOT_MAPPED error seen as follows: rmvol: Removing volume '/dev/disk/dsk4b' from domain 'test' rmvol: Can't move file /test/FILE89 pages rmvol: Error = E_PAGE_NOT_MAPPED (-1035) rmvol: Can't move file /test/FILE89 metadata rmvol: Can't remove volume '/dev/disk/dsk4b' from domain 'test' This patch will also eliminate an ENO_MORE_BLKS error seen when COWing a to a clone file while a rmvol is in progress. The following error will be seen: WARNING: AdvFS cannot copy-on-write data to a clone file. WARNING: encountered the following error: ENO_MORE_BLKS (-1040) WARNING: encountered the following error: ENO_MORE_BLKS (-1040) WARNING: do not continue using the clone fileset. PROBLEM: (94382, 94807, FR_G04495, FR_G05021) (PATCH ID: OSF520-748) ******** This patch corrects a problem in AdvFS where it avoids a potential stranded log record in memory that doesn't get out to disk by fixing a race condition. PROBLEM: (93454) (PATCH ID: OSF520-534) ******** If you use hwmgr to display the inconsistencies in your hardware database and you see the following types of inconsistencies, then you have experienced this problem: ================================================================== hwmgr -show comp -incon HWID: HOSTNAME FLAGS SERVICE COMPONENT NAME ----------------------------------------------- 1024: vega rcd-i iomap SCSI-WWID:01000010:6005-2000-11af-0000 . . . COMPONENT INCONSISTENCY ----------------------- Component (892) has the same name in the cluster database. =========================================================================== It is the "Component (xxx) has the same name in the cluster database." messages that is the signal that you have had this problem. To fix the database, delete one of the Hardware IDs (in this example either 892 or 1024). Typically the higher HWID is the best one to delete. To delete the HWID, use this command (example uses HWID 1024). hwmgr -del comp -id 1024 After deleting that hardware ID, issue a cluster-wide scan to re-discover that device as the appropriate hardware ID. For example: hwmgr -scan comp -cluster -category scsi_bus Be sure to be running with this fix before fixing your system. PROBLEM: (91730) (PATCH ID: OSF520-725) ******** Using hwmgr to delete disk devices can improperly interrupt device scan operations. Most common symptom is scsi device appearing in system with hardware id of "0" and no device special file. PROBLEM: (88592, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-729) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (87224) (PATCH ID: OSF520-660) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (93846) (PATCH ID: OSF520-618) ******** If an application opens a device through the compression device special file and then closes and reopens the device through the non-compression device special file, this problem will occur, and the data will be written compressed. PROBLEM: (92353, BCPM30LC8) (PATCH ID: OSF520-597) ******** Errors occur when running SAS. PROBLEM: (94079) (PATCH ID: OSF520-727) ******** This fix address a problem in the swapping subsystem where the proper locks were not being held during a thread state check. A possible symptom for this problem could be the panic string "thread_setrun: non null runq" with the following stack trace: 4 panic 5 thread_setrun 6 thread_doswapin 7 swapin_thread PROBLEM: (94686) (PATCH ID: OSF520-778) ******** This patch allows the auditing of login and su events based in part on what's in user profiles (for Enhanced Security), the prevailing auditing characteristics of the originating process, and the system-wide audit mask. Previously, only the system audit mask was referenced. HP has corrected this deficiency. For example, assume the following scenario. The system audit mask has login failures reported, but not login successes. The target user profile is set to add in the auditing of successful logins. Under these circumstances, only the login failures would previously have been found in the audit log. PROBLEM: (93770) (PATCH ID: OSF520-741) ******** negative device IDs may be displayed during boot. PROBLEM: (93105) (PATCH ID: OSF520-505) ******** Multithreaded programs making heavy use of malloc and free may see seemingly random segfaults in unnamed routines at addresses near malloc() and free(). The routine free() is in the traceback when the core file is examined. Very occasionally, malloc() may be in the traceback instead of free(). PROBLEM: (94418) (PATCH ID: OSF520-707) ******** After rebooting the cluster, hwmgr -view devices shows (unknow) for device names and running /sbin/dsfmgr -vF cannot correct the problem. PROBLEM: (94312/DE_G04339) (PATCH ID: OSF520-640) ******** This patch addresses an issue when truncating AdvFS files within a trailing fragment. If such a truncation was performed leaving a segment of valid data virtual memory-based accesses (e.g, mmap and NFS server) would erroneously see zeroes for the untruncated data. PROBLEM: (93934) (PATCH ID: OSF520-584) ******** The symptom of this problem is a kernel memory fault, most often originating in the pageout thread. A typical traceback is as follows: 0 boot src/kernel/arch/alpha/machdep.c 1 panic src/kernel/bsd/subr_prf.c 2 trap src/kernel/arch/alpha/trap.c 3 _XentMM src/kernel/arch/alpha/locore.s 4 vm_pageout_scan src/kernel/vm/vm_pagelru.c 5 vm_pageout src/kernel/vm/vm_pagelru.c PROBLEM: (KAOB74580) (PATCH ID: OSF520-683) ******** This patch corrects a problem with could result either in the panic of a cluster member or in inconsistent data when the sbcompress_threshold configurable is set. PROBLEM: (93681, W) (PATCH ID: OSF520-528) ******** Under indeterminate circumstances, when drivers are unloaded or unconfigured, the system may crash if certain kmem_debug flags are set (particulary 0x40 or 0x01). The crash stack backtrace will show remove_dynamic_struct as the problem routine. PROBLEM: (94494) (PATCH ID: OSF520-698) ******** When then Internet Express LDAP Authentication Module is configured onto the system and an LDAP group is created and a user assigned to that group, depending on the placement of LDAP in the /etc/sia/matrix.conf file, the user wouldn't be assigned to the group. A "groups" or "id" would not return the LDAP group. PROBLEM: (92670) (PATCH ID: OSF520-497) ******** This patch prevents a panic in fifo_write with the panic message "NULL fifo_bufhdr append pointer". PROBLEM: (91581, 93794) (PATCH ID: OSF520-723) ******** PROBLEM: When using synchronous IO, a false indication of success will be returned when writing to a file and exceeding the file size limits imposed by the operating system. PROBLEM: _PC_FILESIZEBITS used by pathconf to determine file characteristics was calculated incorrectly. PROBLEM: (93628, 94016) (PATCH ID: OSF520-531) ******** This patch fixes a system panic in AdvFS when an I/O error occurs in the property list component. The panic string seen is "msfs_pl_cur_to_pnt(1) - failed to ref page". PROBLEM: (82424) (PATCH ID: OSF520-771) ******** This patch fixes a problem in the CAM subsystem where it would print out "bad block number" to the error log on a recovered read error. The string has been changed to "block number." PROBLEM: (SSRT2270) (PATCH ID: OSF520-625) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the BIND utility. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (93744, 93747, 94094, 94139, 94123, SSRT2190, SSRT2192, SSRT2257, SSRT2259, SSRT2262) (PATCH ID: OSF520-566) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the chfn, chsh, or passwd utilities. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (85057, 93713) (PATCH ID: OSF520-773) ******** Fix for problem with NUMA Disk Statistics. ------------------------------------------------------------------------ When a system with multiple CPU's issued I/O's to the same disk from more than one CPU, disk usage statistics sometimes showed more than 100% disk utilization. Contributions from different CPU's were not merged correctly. This fix makes the disk usage report correctly on multiple CPU systems, also known as NUMA systems. The problem was visible when using the table() system call or the "collect -sd" command. If you issue a table() call with the argument TBL_DKINFO, the data returned contains an element called di_time. The amount di_time increases between table() calls reflects how much a given disk has been in use. Please refer to the documentation or man pages for details. The command "collect -sd" uses the table() feature and presents the disk usage in the column labeled "%BSY" (percent busy), which should range from 0.00 to 100.00. PROBLEM: (84422, 87576, 87802, 90472, 92015, 93597) (PATCH ID: OSF520-658) ******** This patch fixes many problems with dsfmgr including: command argument parsing, messages and error handling. This patch makes all release versions of dsfmgr functionally the same. Problems: - an illegal input argument causes a core dump This usually occurs when no arguments are entered. - improper error handling by the stat function during boot dsfmgr fails with: dsfmgr: NOTE: creating device special files for system at / dsfmgr: ERROR: stat( "/dev/disk/dsk19a" ) = kernel database - duplicate device ID's +dsk19a /sbin/dn_setup: 1573120 Memory fault - core dumped - the move/exchange may cause data errors This occurs when it encountered a partial set of device nodes. - during boot the following message is seen: ============================= Problem occurred again while booting all nodes of the cluster. The problem occurred on two nodes: tcr6b: Checking device naming: ERROR : DEC_CHW_COMP : /etc/dec_hwc_cdb: invalid database size. Is 412648, sb 412408. ERROR : DEC_CHW_COMP : /etc/dec_hwc_cdb.bak: invalid backup size. Is 412648, sb 412408. bcheckrc: Device Naming failed initial check. Correct errors and then continue or reboot. ============================= This can be caused by a file update during the dsfmgr read of the file. Nothing is wrong and a ^D (ctrl D) will continue the boot again. This fix will detect this senerio and the system will boot without any operator intervention. PROBLEM: (93414) (PATCH ID: OSF520-701) ******** When the system starts swapping, a process goes to sleep in an uninterruptable state (hangs). The condition remedied by this patch is being encountered if there is a vm_object in the process which has the OB_SWAP bit set, but which is not being swapped. PROBLEM: (93805) (PATCH ID: OSF520-562) ******** 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. Compaq has corrected this potential vulnerability.-- PROBLEM: (93087, 93270) (PATCH ID: OSF520-719) ******** This patch removes latencies in ICS threads. PROBLEM: (89120) (PATCH ID: OSF520-691) ******** This is a verification for attributes when registering components with the hardware manager. Attributes type of 'short' and 'char' are not supported. Previously this was not checked and so illegal attributes could have been entered. PROBLEM: (93655) (PATCH ID: OSF520-546) ******** This problem would only be seen under high utilization of DMA mapping resources, i.e., a large number of calls to dma_map_load() and dma_map_unload() in no specific order. Another limiting factor is that this only occurs when 64-bit addressing is used (typically by device drivers), under these high utilization scenarios. The problem will usually result in a system crash (due to a PCI Master Abort or PCI Target Abort), but could also potentially result in data corruption or loss. PROBLEM: (92927, 91550) (PATCH ID: OSF520-631) ******** PROBLEM: (92927) (PATCH ID: ) Some odd byte transfers may fail with an I/O error when reading from a SDLT-120/220 or SDLT-160/320 tape drive connected to a KZPEA adapter. PROBLEM: (91550, CLD CFS.93271) (PATCH ID: ) A "Kernel Memory Fault" panic may occur when an I/O has timed out and is being aborted by the driver. PROBLEM: (93501) (PATCH ID: OSF520-652) ******** There was improper synchronization between threads writing to files via directIO and the copy-on-write of that file's pages if it is cloned. This could allow a stale copy of data to be left in the UBC which would be returned on a subsequent read operation of that page. This would appear to the application as a read of stale data from the file, even though the data on disk was correct. PROBLEM: (92276, 90218, 94063, 94493, 93955) (PATCH ID: OSF520-590) ******** This patch fixes three problems and adds support for one new feature in the "alt" driver for DEGPA Gigabit Ethernet adapters. These problems affect all Tru64 systems containing DEGPA network interfaces. (1) A workaround for a DEGPA hardware bug that can, in rare conditions, cause the machine to panic. When this panic is encountered, the following details will be present in the crash dump: (a) alt_recv_complete will be in the stack trace. (b) The _XentMM trap() will be for memory location 0x50. (2) A fix for a receiver hang that can occur in extremely low memory conditions. When this bug is encountered, the interface will be able to transmit but not receive, so it will not be reachable by any other node on the network. This bug can be verified by checking for a zero value std_rx_buf field in the softc, which means that the adapter has zero mbufs available for receiving: crash> pd alt_softc[0]->std_rx_buf 0 (3) A fix for a DEGPA hardware bug that causes transmission errors on 4G boundaries in physical memory. This can result in NFS hangs and other errors in machines with >4G physical memory. (4) This patch adds tagged ethernet frame capabilities to the "alt" driver, in support of IEEE 802.1Q (VLAN). PROBLEM: (91846) (PATCH ID: OSF520-612) ******** This patch fixes a situation where mounting a valid cdrom the first time fails with 'No valid filesystem exists on the partition' and subsequent mounts of the same cdrom works. For example: 1 eject CD 2 insert v5.1A ASSOCIATED PRODUCTS VOL 1 3 'mount -r /dev/disk/cdrom0c /mnt' works 4 'umount /mnt' 5 eject CD. Swap for 'Associated Products VOL 2' 6 'mount -r /dev/disk/cdrom0c /mnt' fails with 'No valid filesystem exists on this partition' 7 Trying step 6 again will complete fine. 8 Go to step 1. The problem is that code added to the generic cam disk driver to support size expansion and prevent size contraction of hard disks is interfering with removable media devices, such as cdroms and floppy disks. Thus as different sizes of cdroms get swapped, errant behaviour when mounting the cdrom drive can occur. PROBLEM: (94731) (PATCH ID: OSF520-724) ******** This patch adds an event which indicates that the soft or hard error count has changed on the device indentified in the event. PROBLEM: (95248) (PATCH ID: OSF520-806) ******** Advfs domain panics, read/write errors seen after a raid array controller is restarted. The restart can be for any reason. PROBLEM: (90426, 93967) (PATCH ID: OSF520-558) ******** Problem #1: This problem can only occur on NUMA machines. When the underlying condition occurs, user requests to wire a page will fail with an error code of EAGAIN. The condition will never clear on the NUMA node where the wire request is being made, until a system reboot is done. Problem #2: Pages of large shared memory segments which are accessed by programs such as debuggers can run into problems if the shared memory was wired by a user application prior to being accessed by the debugger. The following stack traceback is representative of this problem: 4 panic("u_anon_free: page busy") 5 u_anon_free() 6 u_anon_unmap() 7 u_map_delete() 8 vm_map_remove() 9 procfs_read() 10 vn_read() 11 rwuio() 12 read() 13 syscall() 14 _Xsyscall() PROBLEM: (90277) (PATCH ID: OSF520-777) ******** This patch fixes a system panic, "PWS_CCB_QUE_REMOVE: ccb not on any list" caused by a device or bus reset occuring during the execution of a command to a media changer, like a tape library. Command retries occur to a media changer if a reset is detected after a successful open call to the media changer device completes. The problem is that an internal queue used for command retries becomes corrupted due to a synchronization issue between the media changer driver and common CAM code. PROBLEM: (93908) (PATCH ID: OSF520-552) ******** This patch corrects a failure in the safe_open() routine which caused symbolic links given by a relative path from the current working directory sometimes to give ENOENT errors incorrectly. This was specific to having no 'real' (non-".") leading components before the first symlink was found. PROBLEM: (94478) (PATCH ID: OSF520-642) ******** Fix a rare case of a thread blocking when waiting for memory. you would get a panic THREAD_BLOCK: SIMPLE LOCK OWNED when using AIO. PROBLEM: (93637) (PATCH ID: OSF520-577) ******** In order to see this problem, a program must open a file without direct I/O enabled and access it enough so that a large portion of it is resident in the UBC. The program must then close the file and reopen it with direct I/O enabled. Accesses to the file at this point will become very slow because the pages resident in the UBC need to be removed. This was being done very ineffieciently which was causing a noticeable performance impact. The patch corrects the inefficiency and improves performance in this case. PROBLEM: (94528) (PATCH ID: OSF520-703) ******** kernel memory fault while running with protection on the 128-byte bucket. The typical stack trace is: 0 stop_secondary_cpu 1 panic 2 trap 3 _XentMM 4 u_anon_fault_page 5 u_anon_fault 6 u_map_copy_overwrite 7 procfs_write PROBLEM: (94865) (PATCH ID: OSF520-756) ******** This patch allows the Event Manager daemon, evmd, to stop listening on its default tcp port 619. This capability is available to single systems. This capability cannot be enabled on a system that is a member of a cluster. To prevent the Event Manager daemon from listening on its default tcp port, add the following line to /etc/evmdaemon.conf. port -1 You must stop and restart the Event Manager for the change to be effective. Enter the following commands. /usr/sbin/evmstop /usr/sbin/evmstart A message will be written to /var/evm/adm/logfiles/evmdaemon.log indicating the status of the remote port. On a clustered system there will be a message indicating that the remote port cannot be turned off. PROBLEM: (79936) (PATCH ID: OSF520-581) ******** The hwmgr -show component -incon command may falsely report an inconsistency in a cluster when there is none. The inconsistency reported is: COMPONENT INCONSISTENCY ----------------------- Component should not have an entry in the cluster database but it does. PROBLEM: (94694,) (PATCH ID: OSF520-710) ******** If some nodes of a cluster are rebooted, and the nodes being rebooted has access to a quorum disk, then sometimes the node being rebooted or a up node crashes with kernel memory fault. PROBLEM: (HGO115794, KAOZ30089, KAOZ30089) (PATCH ID: OSF520-494) ******** This correction fixes the counting of files in AdvFS, which was reporting no available inodes when there were plenty. PROBLEM: (94224) (PATCH ID: OSF520-720) ******** Some CDROM media created by third party software can be mounted, but not viewed with commands such as ls() or find(). PROBLEM: (93869, 93585) (PATCH ID: OSF520-541) ******** This patch replaces the system panics caused by "Can't clear bit twice" with a domain panic. Panic strings include: "bad v0 frag free list" "get bf set attr failed." "invalid fragSlot" "bs_frag_alloc: invalid frag" "bs_frag_alloc: invalid frag group Also included in this path is some code clean up. There are times when a routine will only return success, yet we were checking return value for failure. PROBLEM: (94297) (PATCH ID: OSF520-616) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. A malicious user can attempt to subvert a program file that has the setuid or setgid privilege and possibly execute commands at an elevated privilege level. HP has corrected this potential vulnerability. PROBLEM: (75878) (PATCH ID: OSF520-596) ******** Change how u.u_ssize is set to get correct stack sizing information. Without this change accounting memory usage may be incorrectly reported as a very large number. PROBLEM: (93813) (PATCH ID: OSF520-611) ******** This patch fixes a potential deadlock when a multi-threaded process calls fork() in one thread and simultaneously calls exit() in another. PROBLEM: (94485) (PATCH ID: OSF520-670) ******** This patch fixes a memory leak in the NFS server when it receives malformed NFS packets. If there are a large number of bad NFS packets, then the system will eventually run out of free memory, resulting in messages like "vmunix: malloc_wait:1: no space in map" being displayed on the console. PROBLEM: (88837) (PATCH ID: OSF520-696) ******** This patch fixes a situation in which attributes are viewed via hardware manager. The values display might not be correct. The problem is in the comparison of like data types. The fix is to cast the data types to match each other before the comparison is done. PROBLEM: (TKT327302) (PATCH ID: OSF520-730) ******** This patch fixes a problem in the kernel network subsystem that caused a kernel memory fault panic in the routine m_adj(). PROBLEM: (94701) (PATCH ID: OSF520-799) ******** This patch prevents memory troller from starting on aluminum ev68 chips. PROBLEM: (88588) (PATCH ID: OSF520-610) ******** 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 access. Compaq has corrected this potential vulnerability. PROBLEM: (91941) (PATCH ID: OSF520-772) ******** This problem only happens when a deleted file is held open and the system crashes. The quotas are adjusted during the final close for a file that is deleted. When a deleted file is held open and the system crashes, the code to adjust the quotas is not called. The storage for the file does get returned since it is on the deferred delete list and that is processed during recovery. The fix is, during processing of the deferred delete list, to open the file and close it. This will cause quota processing to occur and also tag file and frag processing. PROBLEM: (IPMT) (PATCH ID: OSF520-692) ******** This patch would only be applicable if one is using tapes with programs which are not generally used for writing and reading tapes. In other words, regular tape backup software and programs like tar and cpio would have no need for this patch. Only "homegrown" or other programs which might write to tapes with one block size, and then read the same tape with a smaller block size, would have use for this patch. The patch provides a configurable setting which can be set to cause an error to be returned from any read from tape that requests fewer bytes of data than exist in the tape block being read. PROBLEM: (HPAQ70382) (PATCH ID: OSF520-706) ******** Fix for kernel memory fault panic in the IP multicast loopback code. One would only see this panic if there are IP multicast packets while someone is using packetfilter to monitor the interface. 4 panic src/kernel/bsd/subr_prf.c : 1353 5 trap src/kernel/arch/alpha/trap.c : 2266 6 _XentMM src/kernel/arch/alpha/locore.s : 2143 7 _OtsMove src/kernel/arch/alpha/ots_move_alpha.s : 1762 8 m_copydata src/kernel/bsd/uipc_mbuf.c : 865 9 eestart_locked src/kernel/io/dec/netif/if_ee.c : 4839 10 eestart src/kernel/io/dec/netif/if_ee.c : 4530 11 ether_output src/kernel/net/if_ethersubr.c : 1624 12 ip_output src/kernel/netinet/ip_output.c : 998 13 udp_output src/kernel/netinet/udp_usrreq.c : 1954 14 udp_usrreq src/kernel/netinet/udp_usrreq.c : 2153 15 sosend src/kernel/bsd/uipc_socket.c : 3109 16 sendit src/kernel/bsd/uipc_syscalls.c : 1154 17 sendto src/kernel/bsd/uipc_syscalls.c : 869 18 syscall src/kernel/arch/alpha/syscall_trap.c : 725 19 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 PROBLEM: (93039, BCGM603V0,) (PATCH ID: OSF520-585) ******** This fix prevents a sign promotion generated by the compiler while comparing 32 bit int variable with 64 bit unsigned long variable. This leads to an incorrect comparison which, in turns, leads to an unnecessary directory lookup warning message on the nfs client when the client receives a directory fileid with bit 31 sign bit on. On a lesser extend, it also causes a slight nfs client caching performance penalty. PROBLEM: (91290) (PATCH ID: OSF520-781) ******** If you reboot immediately after entering a hwmgr -redirect scsi command then you will only boot to single user mode with the following error being displayed: bcheckrc: Device Naming failed boot configure or verify Please correct the problem and continue or reboot INIT: SINGLE-USER MODE PROBLEM: (93310) (PATCH ID: OSF520-522) ******** This patch corrects the behavior of the NFS client negative lookup result cache. The NFS client has a mechanism that caches negative lookup results to avoid making repeated RPC calls. This cache over-aggressively cached negative lookup results, potentially denying access to a file incorrectly until the cache entry timed out. PROBLEM: (93931, 91760) (PATCH ID: OSF520-697) ******** This patch fixes an emx driver boot issue while booting certain Mustang and Marvel configurations in lockmode=4. Additionally, this patch fixes a rare heavy load (low memory) IO hang. PROBLEM: (93714, 88135, 92143, 86119) (PATCH ID: OSF520-667) ******** PROBLEM: audit_tool does not correctly display information for a fcntl F_DUPFD event. PROBLEM: audit_tool -R command causes a core dump. PROBLEM: The audit_tool generates unaligned access messages for the exportfs system call when recording both writeaddrs and rootaddrs vectors. PROBLEM: (93448, 93445, 93446, 93447, 93448, 93449, 93524) (PATCH ID: OSF520-744) ******** This patch prevents a situation where the system will panic when certain system calls are made with bad input. PROBLEM: (90064) (PATCH ID: OSF520-641) ******** This patch addresses two potential problems with the NFS version 3 client. The first is where a COMMIT RPC retransmission could complete the RPC before the actual commit was complete. The second is where colliding commits can result in a return before the unstable data is committed to storage. PROBLEM: (DE_G03995) (PATCH ID: OSF520-537) ******** This fixes a problem in the VM subsystem that could cause a crash with the panic string "vm_page_ssm_unwire". An example stack trace: 4 panic 5 vm_page_ssm_unwire 6 u_ssm_unwire 7 u_ssm_fault 8 vl_unwire 9 u_map_wire 10 lw_unwire_new 11 vm_map_pageable PROBLEM: (89330) (PATCH ID: OSF520-506) ******** This fix allows LSM to do a better job at placing its meta data on devices that don't have a single point of failure. It does this by properly reporting information to LSM through the hardware management interfaces by fixing a "hardware component" cache that was being set incorrectly. PROBLEM: (92922) (PATCH ID: OSF520-554) ******** The algorithm for moving buffers between 2 of the I/O queues was inefficient and allowd the possibility of a lock timeout on the vdIoLock. This patch makes this movement much more efficient and avoids the timeout. The timeout would be seen as a system panic with a message similar to the following: mcs_lock: time limit exceeded pc of caller: 0xffffffff00235364 lock address: 0xfffffc001f8e77a8 lock info addr: 0xfffffc00014fcea0 lock class name: vdT.vdIoLock current lock state: 0xc00300da00010007 (cpu=3,pc=?,busy) PROBLEM: (91602, 92396) (PATCH ID: OSF520-580) ******** PROBLEM: df() command on dvdfs does not list size of the DVD media. PROBLEM: mount() command displays "pathconf" error when dvdfs is used on the system. PROBLEM: some commands (i.e. gzip) that are executed from DVD media will not execute at all. PROBLEM: (91901, 93789) (PATCH ID: OSF520-680) ******** advscan can be fooled into thinking everything is OK, when it is not. If you create a domain and add a volumes to it. Say the domain is TEST and two volumes are ${DISK}a and ${DISK}b. Now do the following: mkdir /etc/fdmns/BAD mv /etc/fdmns/test/${DISK}b /etc/fdmns/BAD/ when advscan is run on ${DISK}, it will report everything as ok. : Actual partitions found: ${DISK}a ${DISK}b Now when you try to mount the domain, it will fail: mount TEST#TEST /mnt /etc/fdmns/TEST has 2 links. TEST#TEST on /mnt: I/O error The new behavior will yield: Actual partitions found: ${DISK}a ${DISK}b *** Incorrectly located in *** /etc/fdmns/BAD The mount will still fail, but it is now expected. The other issue will now print an error message like: AdvFS I/O error: Domain#Fileset: dombac#fsetbac Mounted on: /bac Volume: /dev/disk/dsk630c Tag: 0x000000c1.8001 Page: 548676 Block: 2431675264 Block count: 256 Type of operation: Write Error: 30 (see /usr/include/errno.h) <<<---NEW ... PROBLEM: (HPAE6035S) (PATCH ID: OSF520-563) ******** This patch prevents false invalid Inquiry data error reports during boot. PROBLEM: (93455) (PATCH ID: OSF520-504) ******** The mmap syscall can accept some bad arguments, such as negative lengths. This can lead to a panic "malloc: invalid size" with the following stack trace: 4 panic("malloc: invalid size") 5 malloc_internal() 6 u_anon_init() 7 vm_object_allocate() 8 u_map_enter() 9 u_anon_create() 10 smmap() 11 syscall() 12 _Xsyscall() PROBLEM: (94736) (PATCH ID: OSF520-714) ******** A taso application begins to fail memory allocations after an mmap is bumped to be above the heap, since the space below the stack is in use. (calls to malloc, etc.) PROBLEM: (94209) (PATCH ID: OSF520-736) ******** /sbin/ddr_config is a tool that reads the text file /etc/ddr.dbase and produces the binary Dynamic Device Recognition (DDR) database file /etc/ddr.db that the Tru64 Operating System reads to obtain device driver settings. One of the optional parameters for a device in /etc/ddr.dbase is ReadyTimeSeconds, it determines how long before an I/O request times out on that device. Some tape devices can take 300 seconds (5 minutes) or more to become ready. If the ReadyTimeSeconds value in /etc/ddr.dbase is larger than 255, /sbin/ddr_config will print an error message, refuse to accept it and will revert to the default value of 45 seconds. If you have a tape drive that takes a long time to get ready and you experience I/O timeouts, consider installing this patch. It contains a new ddr_config that allows ReadyTimeSeconds values up to 86400 seconds (24 hours). You may then edit /etc/ddr.dbase (or a copy of it) and increase ReadyTimeSeconds for your tape drive, for example: ReadyTimeSeconds = 300 Recompile /etc/ddr.dbase by issuing the command: ddr_config -c [filename] If you make sure that all devices of that type are unmounted and nobody is using any of them when you issue ddr_config, the change will take effect without rebooting your system. PROBLEM: (93126, 93724) (PATCH ID: OSF520-545) ******** Excessive FIDS lock contention is observed when large number of files using system based file locking. Result from "lockinfo -sort=misses -d 20 -f 200 -p 25 -l 20" will show at the top of the list with a high miss rate. PROBLEM: (SSRT2266) (PATCH ID: OSF520-687) ******** A potential security vulnerability has been identified in the HP Tru64 UNIX operating system that may result in denial of service. This may be in the form of local and remote security domain risks. The following potential security vulnerability has been corrected: o SSRT2266 IGMP (Severity - High) PROBLEM: (88667) (PATCH ID: OSF520-775) ******** This patch fixes the reporting of device monitoring events and hardware errors during disk recovery from the disk driver to the binary errlog. The first problem is that the message, "Device monitoring events for Test Unit Ready CCB" is incorrectly getting logged into the binary errorlog. This message is intended to get logged only when a disk is not responding. It is currently getting logged under conditions when the disk has actually responded. This results in the saturation of errant device monitoring events into the binary errorlog. The second problem is that the disk recovery process misses an early opportunity to detect and report a nonrecoverable hardware error. Instead of immediately logging a "Recovery failed" message and stopping the recovery when a nonrecoverable hardware error is reported, the disk driver is logging a "Recovery progress event, this is NOT an error" information message that includes event information indicating a "HARDWARE ERROR - Nonrecoverable hardware error" event has occurred and continues with the recovery process. This results in a confusing binary errorlog message and the unnecessary continuation of a recovery process that will not succeed. PROBLEM: (BCGM5159Z) (PATCH ID: OSF520-711) ******** This patch forces a domain panic instead of a system panic if AdvFS metadata is discovered to be incorrect in frag_group_dealloc. PROBLEM: (89093) (PATCH ID: OSF520-716) ******** Offlining a CPU with bound process(es) can lead to a "malloc_check_checksum: memory pool corruption" panic. 0 stop_secondary_cpu 1 panic 2 malloc_check_checksum 3 malloc_internal 4 _ms_malloc 5 _ftx_start_i 6 bmt_free_bf_mcells_i 7 bmt_free_bf_mcells 8 del_dealloc_stg 9 stg_remove_stg_finish 10 bs_close_one 11 msfs_inactive 12 vrele 13 vn_close 14 closef 15 close 16 syscall 17 _Xsyscall PROBLEM: (92310) (PATCH ID: OSF520-787) ******** The mlockall() function, when given the MCL_FUTURE flag, is supposed to cause all future memory allocations in that process to become wired. However, memory obtained from the mmap() function was not being wired correctly after using mlockall(). This resulted in low performance from the mmap memory pages. PROBLEM: (86918) (PATCH ID: OSF520-770) ******** The problem is that addvol allows a HSG/HSZ disk partition to be added to an 'on-line' (or off-line), existing domain, when the disk partition can not access all the blocks that the disklabel indicates, and consequently, all the blocks added to the domain. This due to the disklabel no longer being valid. PROBLEM: (DE_G04979) (PATCH ID: OSF520-746) ******** In a non-C locale, extended regular expressions of the form "[a-z]{m,n}" and ".{m,n}" may be handled incorrectly, as if the interval expression is {m,n+1}. This patch fixes the problem. PROBLEM: (94370) (PATCH ID: OSF520-606) ******** This patch fixes a problem in the cluster, where non-default alias mounting feature was disabled. PROBLEM: (94189, 94095, SSRT, SSRT) (PATCH ID: OSF520-630) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be comprimised when a buffer overflow occurs in the ypmatch and traceroute utilities. Buffer overflows are sometimes exploited in an attempt to subvert the funcuion of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (94091) (PATCH ID: OSF520-690) ******** Fix for internal kernel panic "kernel memory fault" in imm_page_to_xtnt() This fix locks the extent map of the clone while transferring storage to it during a truncate on the original file. We do this because a migrate on the clone at the same time resulted in the extent map becoming invalid in the middle of the simultaneously executing migrate. A KMF would occur in migrate because the extent map was freed out from under migrate by xfer_stg->xfer_stg_to_bf() and xfer_stg->merge_xtnt_maps. This kernel panic occurs infrequently when one thread is adding truncating storage from a file and trasferring that storage to its clone file AND another thread is actively migrating the same file. PROBLEM: (93539) (PATCH ID: OSF520-586) ******** This patch handles potential problems when reading files from an NFS server that reside on a third-party filesystem. The NFS server read mechanism was recently reworked to use the buffer cache to read the underlying filesystem data. These changes did not handle the case where the underlying filesystem did not implement the buffer cache callbacks and resulted in a kernel memory fault panic with a stack trace similar to the following: 6 _XentMM 7 rfs_read_common 8 rfs3_read 9 rfs_dispatch 10 nfs_rpc_recv 11 nfs_rpc_input 12 nfs_input 13 nfs_thread This patch detects, intercepts and handles requests to underlying filesystems that do not support the buffer cache callbacks. PROBLEM: (82026) (PATCH ID: OSF520-796) ******** This is a cluster specific fix regarding mounting the cluster root comain with disks private to different cluster members. Currently the cluster will hang as it cannot get remote device information that early in boot. With this fix, remote device information can be obtained from another cluster member as needed. If used, the following new warning will appear on the console during boot from the cluster member serving cluster root. WARNING: cluster root devices are on private buses! This configuration is not recommended, but should not result in an unbootable cluster. Currently, this is with respect to cluster root domains that are not under LSM control. PROBLEM: (92947) (PATCH ID: OSF520-538) ******** u_stack_migrate needs to call vmpolicy_cleanup if vmpol_save is non-zero. Doing this will clean-up vm policy allocation done by vmpolicy_add(). PROBLEM: (73421) (PATCH ID: OSF520-632) ******** This problem was discovered by code inspection. The problem is that a routine in hwc_subsys.c would invoke MALLOC with a simple lock held. This would cause a problem if the malloc needed to block. PROBLEM: (94417) (PATCH ID: OSF520-737) ******** The audit_tool search algorithms did not differentiate between prived, non_prived, unset audit uids. PROBLEM: (88114, 93775) (PATCH ID: OSF520-543) ******** The accounting for moving of buffers onto the device queue in AdvFS failed to include buffers being moved from the blocking queue. This would include metadata buffers and buffers for files opened for directIO. The result is that when monitoring IO via advfsstat, these buffers were not represented. In some cases, it appeared that IO was not happening. PROBLEM: (87975, SSRT0711U) (PATCH ID: OSF520-668) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (94251, 94298) (PATCH ID: OSF520-600) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (88228, 88707, 87770, 88077, 89681, 87963, 82569, 86505, 87180, 87497, 86504) (PATCH ID: OSF520-085) ******** This patch, which installs DECthreads V3.18-133, fixes the following problems: The fork() system call may fail when a threaded process has several threads and uses thread local storage. The child process terminates immediately with a SEGV. pthread_rad_bind may fail with a SEGV. DECthreads library may fail reporting a krnMcsLock deadlock bugcheck. Data corruption errors might occur during thread creation. DECthreads library may fail reporting a pthread_rwlock_tryrdlock bugcheck. SCS threads don't go into baby child mode, causing errors in the ladebug debugger. The close() system call may hang in the child of a forked threaded process. pthread_mutex_destroy may return EBUSY when trying to delete a mutex that is no longer used. PROBLEM: (75-55-307, 70-25-17) (PATCH ID: OSF520-308) ******** This patch installs DECthreads V3.18-138 which fixes a problem that may occur with threaded applications when using recursive mutexes and condition variables. PROBLEM: (92716, 70-25-31, 70-25-7) (PATCH ID: OSF520-419) ******** This patch installs DECthreads V3.18-144, the latest version of the Compaq POSIX Threads library for Tru64 UNIX V5.1A. This patch fixes a bug that caused the threads library to not handle informational error codes from the kernel correctly. This bug might result in a threaded application process terminating with the DECthreads bugcheck message: % Reason: upcThreadBlocked: (os/kern) not receiver (7) nxm_thread_kill PROBLEM: (70-25-29, 92057) (PATCH ID: OSF520-388) ******** This patch installs DECthreads V3.18-141 which fixes problems that may affect threaded programs running on Tru64 UNIX V5.1A. This patch specifically addresses two problems: 1. The symbolic name table(), upon which pthreads has a dependency, may be preempted by application code. This patch introduces a fix to make the pthreads library immune from the preemption of table(). 2. The initial address of the Stack Pointer in a new PCS thread was not properly aligned. This patch fixes that problem with correct octaword alignment of the user thread Stack Pointer. PROBLEM: (75-13-854, 70-25-31, 70-25-40, 70-25-444, 75-13-878, 70-25-46, 94808) (PATCH ID: OSF520-743) ******** This patch installs DECthreads V3.18-148, the latest version of the Compaq POSIX Threads library for Tru64 UNIX V5.1A. This patch address issues in both Tru64 UNIX and OpenVMS, including: - compile time error when attempting to include , error: %CC-E-UNDECLARED, In this statement, "NULL" is not declared - libpthreads was attempting to force the initial thread to service ASTs when it was suspended by Java garbage collection. - improving DECthreads internal trace points. - fixing a problem caused by deep recursions involving the inner-mode semaphore (IMS) free upcall. These can be deep enough (65 or more levels) to overflow a null thread's call stack. - The thread library may wake up the wrong thread whan a mutex is unlocked. As a result, an application may experience threads running out of order. PROBLEM: (70-25-53) (PATCH ID: OSF520-783) ******** This patch installs DECthreads V3.18-150, the latest version of the HP POSIX Threads library for Tru64 UNIX V5.1A. This patch includes a fix for a problem with how waiting threads are unblocked in response to the expiration of timed waits. Threaded applications using timed condition variable waits, pthread_cond_timedwait, or timed delays, pthread_delay_np, may experience a hang without this patch. PROBLEM: (cfs.91538) (PATCH ID: OSF520-726) ******** This patch allows manual shared access coordination of open SAN accessable tape devices. The mt command has been enhanced to allow for tape devices to be reserved (via the scsi-2 reserve command) and released (via the scsi-2 release command). The new commands are: mt reserve mt release mt tur Reserve also includes modifiers: -t (force a target reset only on the active path before the reserve) -f (force a target reset on all available paths before the reserve) -l (force a lun reset only on the active path before the reserve) -r (force a lun reset on all available paths before the reserve) This command should be used prior to (mt reserve) the use of an application that is not shared tape aware. After completion, this command should be used again (mt release). The mt tur command can be used to determine if another application has already reserve the tape. The force options above should only be used when it is known that the device is NOT being used by another user and that user simply forgot to release the device after they had finished; any other use of the force options can lead to possible data corruption by allowing multiple users to access the device at the same time. PROBLEM: (87635, 87833, 90019, 90048, 90055, 90162, 90165, 90237, 90330, 90416, 90583, 90808, 90837, 91305, 91605, 92186, 92384, 93083, 94461, 94886) (PATCH ID: OSF520-801) ******** PROBLEM (87635) (PATCH ID: ) It is possible for an I/O to be returned to the driver by the adapter firmware with no status if the I/O was aborted during a burst of bus resets. The result was an error of the type "Unexpected status returned - 0x0" being logged in the binary error log. The I/O itself would be reissued by the driver. PROBLEM: (87833, 90019, 90048, 90162, 90165, 90237, 90330, 90583, 90808, 91305, 92186, 92384, 93083) (PATCH ID: ) A system hang, bus hang or panic could occur if a burst of bus resets are received. A timing window exists where by the adapter still has context of an I/O which had been aborted because of a bus reset. Depending on the state of that I/O this could result in a Machine Check or Kernel Memory Fault panic of the system. This could also result in the driver's failure to clear an internal state flag causing a bus or system hang condition. PROBLEM (90055, 90416, 90837, 90165) (PATCH ID: ) The driver failed to handle data underrun conditions properly which could result in a read request being returned with a byte count that is more than what was actually read. PROBLEM (94461) (PATCH ID: ) A system hang could occur during a system boot if a target failed to respond to the driver's inquiry command. If the command timed out the driver failed to return the appropriate error to the configuration subsystem. As a result the inquiry command was reissued. This results in an endless loop if the target fails to ever respond. PROBLEM (94886) (PATCH ID: ) A Kernel Memory Fault panic could occur during boot if the verification of the adapter should fail. This condition could occur if an unsupported variant of the adapter is found on the system or if an error occurred when trying to access the adapters registers during initialization. PROBLEM: (93733) (PATCH ID: OSF520-574) ******** - NHD6 enablers for future hardware support of a Smart Array controller - On an idle system with Smart Array 5300 series controllers installed, a heartbeat pending error could occur as a result of a missed thread wake up. This error will be logged to the binary error log as "ciss_heartbeat, Heartbeat pending...resetting controller". The controller will then be reset. PROBLEM: (SSRT2266) (PATCH ID: OSF520-810) ******** PROBLEM: (SSRT2266) (PATCH ID: ) A potential security vulnerability has been identified in the HP Tru64 UNIX operating system that may result in denial of service. This may be in the form of local and remote security domain risks. The following potential security vulnerability has been corrected: o SSRT2266 IGMP (Severity - High) PROBLEM: (95110) (PATCH ID: OSF520-811) ******** This patch fixes a potential floating point error in threaded applications. Without this solution, it is possible for a process to get different floating point values after a context switch. PROBLEM: (SSRT2322) (PATCH ID: OSF520-816) ******** A potential security vulnerability has been identified in the HP Tru64 UNIX operating system which may result in a Denial of Service (DoS). This may be in the form of local and remote security domain risks. The following potential vulnerability has been corrected: o SSRT2322 - BIND resolver (Severity - High) PROBLEM: (93707, 93979, 94862, 94962, 94830, 94815, 94569, 94907) (PATCH ID: OSF520-559) ******** This patch provides support for DEGXA Gigabit Ethernet devices, including the ES25 onboard 10/100/1000 Ethernet port. For systems with existing DEGXA support, this patch fixes numerous link-related problems, including flow-control and auto-negotiation issues. PROBLEM: (95207) (PATCH ID: OSF520-835) ******** This patch fixes a race condition introduced by a previous patch. PROBLEM: (95214) (PATCH ID: OSF520-845) ******** The DS20L now supports binglog text messages when an environmental system event occurs. In addition, because of the DS20L's thermal sensitivity, the environmental thermal thresholds have been lowered. PROBLEM: (none) (PATCH ID: OSF520-836) ******** NHD6 installs failed to see new disk information PROBLEM: (95115, 95116, 95117, 95118) (PATCH ID: OSF520-846) ******** Not applicable. PROBLEM: (95387) (PATCH ID: OSF520-877) ******** This patch fixes a flaw in the NFS server which could cause it to crash upon reception of malformed UDP input. PROBLEM: (92811, 95443) (PATCH ID: OSF520-903) ******** This problem caused a number of error conditions to be seen during HSZ and HSG failovers. These conditions include; ADVFS domain panics, kernel memory faults, and stalled IO. PROBLEM: (95407, 95449) (PATCH ID: OSF520-887) ******** This patch addresses two potential crashes with the NFS server. The first can occur with concurrent read and truncate behavior on an AdvFS file and could result in a system crash with a kernel memory fault dereferencing a null pointer. The second can occur with malformed or malicious NFSv3 READDIR or READDIRPLUS RPCs, where the desired return buffer size is specified as zero. The size used could result in the dereferencing of a null or invalid pointer. PROBLEM: (95674) (PATCH ID: OSF520-1003) ******** Some networking applications, especially X.25 and X.29, stopped working as expected after patch 807 in patch kit 3 because of interactions with security-related fixes in that patch and how fstat(2) behaves on their sockets. HP has fixed this deficiency. In particular, x29logind would fail to answer incoming calls. The daemon.log syslog files would show lines with the following message from x29logind: Cannot read packet sizes from port: Socket operation on non-socket PROBLEM: (BCGMC00N0, BCGMC00MX) (PATCH ID: OSF520-983) ******** This patch is required for Sierra systems to prevent issues in the DCE/DFS file system when pages are being flushed as part of a vnode. PROBLEM: (95605, 94863, 95343, 95419, 95531, 95542) (PATCH ID: OSF520-972) ******** This patch fixes two problems in the bcm driver. The first is where the driver could query the adapter link information while the adapter is in the midst of resetting. This causes a machine check and ultimately a crash. The second is where the driver provides the wrong DMA address to the adapter, causing the adapter to reuse a receive mbuf which has already been given to the TCP/IP stack. This usually causes a crash. PROBLEM: (95445, 95446, 95596, 95611) (PATCH ID: OSF520-963) ******** A command timeout may occur due to the smart array driver losing a command completion. If the following error log entry is generated, this patch should be loaded. Sequence number of error: 633 Time of error entry: Sun Nov 24 19:39:10 2002 Host name: caninedelig SCSI CAM ERROR PACKET SCSI device class: CISS (Smart Array) Bus Number: 5 Target Number: 4 Lun Number: 0 Routine name that logged the event: ciss_cmd_timeout Event information: Command timed out...resetting controller Event information: Active CCB at time of error PROBLEM: A disklabel command can fail if the smart array controller is in error recovery when the command is executed. If a disklabel command fails and the following error log entry is generated, this patch should be loaded. Sequence number of error: 673 Time of error entry: Sun Nov 24 19:39:12 2002 Host name: caninedelig SCSI CAM ERROR PACKET SCSI device class: DISK Bus Number: 5 Target Number: 2 Lun Number: 0 Routine name that logged the event: cdisk_online Event information: ccmn_path_setup3 has reported no viable paths Hardware detected event: Hard Error Detected Event information: Hardware ID = 86 Device Name: COMPAQ LOGICAL VOLUME 2.94 PROBLEM: Kernel Memory Fault. If the following stack trace is seen in the crash dump, this patch should be loaded. 1 panic 2 event_timeout 3 printf 4 panic(s = 0xfffffc0000bb0be0 = "kernel memory fault" 5 trap 6 _XentMM 7 dma_get_private 8 ciss_append_handle 9 ciss_map_data PROBLEM: Kernel Memory Fault. If the following stack trace is seen in the crash dump, this patch should be loaded. 1 panic 2 event_timeout 3 printf 4 panic(s = 0xfffffc0000bb0be0 = "kernel memory fault" 5 trap 6 _XentMM 7 ciss_ReportLogLUN 8 xpt_callback_thread PROBLEM: (STL226954, 87527, 87856) (PATCH ID: OSF520-028) ******** This patch corrects the problem in which /usr/bin/ksh hangs for certain scripts that contain wait(1). PROBLEM: (90927, SSRT1-40U, SSRT1-41U, SSRT1-42U, SSRT1-45U, SSRT1-48U) (PATCH ID: OSF520-217) ******** 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 access. Compaq has corrected this potential vulnerability. In addition the following changes were made: - shell inline input files are more secure - sh noclobber and new constructs added - updated mkdir system call Updated sh, csh and ksh ----------------------- The updated shells in this kit all implement the following changes when processing shell inline input files: - File permissions allow only read and write for owner - If excessive inline input file name collisions occur the the following error message will be returned: "Unable to create temporary file" sh noclobber option and >| , >>| constructs added ------------------------------------------------- A noclobber option similar to that already available with csh and ksh has been added to the Bourne shell. When the noclobber option is used (set -C), the shell behavior for the redirection operators > and >> changes as follows: - For > with noclobber set, sh will return an error rather than overwrite an existing file. If the specified filename is actually a symlink, the presence of the symlink satisfies the criteria "file exists" whether or not the symlink target exists, and sh returns an error. The >| construct will suppress these checks and create the file. - For >> with noclobber set, output is appended to the tail of an existing file. If the file does not exist, or the filename is actually a symlink whose target does not exist, sh returns an error rather than create the file. The >>| construct will suppress these checks and create the file. ksh noclobber behavior clarified -------------------------------- For > with noclobber set, ksh returns an error rather than overwrite an existing file. If the filename is actually a symlink, the presence of the symlink satisfies the criteria "file exists" whether or not the symlink target exists, and ksh returns an error. The >| construct will suppress these checks and create the file. For >> with noclobber set, output is appended to the tail of an existing file. If the filename is actually a symlink to a non-existent file, ksh returns an error. csh noclobber behavior clarified -------------------------------- For > with noclobber set, csh returns an error rather than overwrite an existing file. If the filename is actually a symlink, the presence of the symlink satisfies the criteria "file exists" whether or not the symlink target exists, and csh returns an error. The >! construct will suppress these checks and create the file. For >> with noclobber set, output is appended to the tail of an existing file. If the filename is actually a symlink to a non-existant file, csh returns an error. The >>! construct will suppress these checks and create the file. Updated mkdir system call and command ------------------------------------- This kit reverts the mkdir system call, and thus the mkdir command, to its Tru64 UNIX V4.n behavior with respect to symlinks. For the unusual case where a symlink is used as the very last elment of a mkdir path, the mkdir syscall nows returns an error than create the target. If, for some reason, you want mkdir to follow the symlink you can do so by making the last character of the mkdir pathname a slash. The following example depicts how to get mkdir to follow the symlink: - If /var/tmp/foo is a symlink to /usr/xxx, which does not exist, then mkdir("/var/tmp/foo",0644) will return an error but mkdir("var/tmp/foo/",0644) will create /usr/xxx. Mkdir behavior can also be controlled systemwide by an addition to the sysconfig options for the vfs subsystem. The new sysconfig option "follow_mkdir_symlinks" defaults to 0, specifying the secure symlink behavior. Changing this option to 1, which Compaq strongly discourages, will cause mkdir to follow symlinks. PROBLEM: (89814, 117-1-18182) (PATCH ID: OSF520-228) ******** This patch corrects a problem in which ksh fails to substitute the tilde (~) character for a user's home directory after an assignment using the "#" or "%" characters has been used. PROBLEM: (90369, FR_G02425) (PATCH ID: OSF520-208) ******** This patch fixes a problem with ksh. When a ksh menu is started from within user's .profile, ksh will not stop when the telnet session is stopped. PROBLEM: (TKT244440) (PATCH ID: OSF520-227) ******** While in an Asian locale (such as Japanese) and executing a ksh command that deals with directories with Asian language names, a segmentation fault and core dump may occur. This patch fixes this problem. PROBLEM: (85854) (PATCH ID: OSF520-526) ******** Bourne shell has a major problem when you use type utility. When you run type utility with file path of more than 69 chars, then sh generates invalid memory reference, and thus causes memory fault. When ever memory fault is generated, it calls the signal hadler fault() routine, and this intern calls growstack() routine. When multiple times called fault(), and growstack drastically increases stack area, and thus this process will not allow other process to make use of swap space. Hence, all applications will shutdown, and system hangs. The problem is so happened that static char array size msgbuf[128] is used to store standard o/p of type utility. When file path is 69 characters, then overall o/p of type utility will become more than 128 chars and thus running out of space. To avoid this problem have allocated memory dynamically of size standard o/p of type utility. Steps to reproduce: ------------------- #mkdir -p caopreprod/apl/dec04/fluent/fluent5.3/alpha/3d_node #touch caopreprod/apl/dec04/fluent/fluent5.3/alpha/3d_node/fluent_smpi.5.3.18 #chmod +x caopreprod/apl/dec04/fluent/fluent5.3/alpha/3d_node/fluent_smpi.5.3.18 # type sh sh is /sbin/sh # sh # type caopreprod/apl/dec04/fluent/fluent5.3/alpha/3d_node/fluent_smpi.5.3.18 > -> swap space below 10 percent freeswap space below 10 percent free Unable to obtain requested swap space Unable to obtain requested swap space no space PROBLEM: (117-1-19737) (PATCH ID: OSF520-437) ******** This fix corrects a problem in which sh was using a high amount of CPU time. PROBLEM: (117-1-19056) (PATCH ID: OSF520-445) ******** This fix corrects a problem in which ksh did not clean up the processes associated with a terminal once the window was closed. PROBLEM: (92820) (PATCH ID: OSF520-595) ******** 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 access. HP has corrected this potential vulnerability. PROBLEM: (94301) (PATCH ID: OSF520-623) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the ksh utility. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (92819) (PATCH ID: OSF520-626) ******** 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 access. HP has corrected this potential vulnerability. PROBLEM: (94525) (PATCH ID: OSF520-656) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised when a buffer overflow occurs in the sh utility. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. HP has corrected this potential vulnerability. PROBLEM: (EVT38717A, 81694) (PATCH ID: OSF520-001) ******** This patch fixes a problem in which the 'vi' editor core dumps when it finds invalid syntax during a substitute operation. PROBLEM: (89611) (PATCH ID: OSF520-143) ******** In a LAN cluster, the stopping or restarting of the network would cause the cluster interconnect interface to be stopped causing a loss of cluster communication. This fix ensures that cluster interfaces are not stopped. PROBLEM: (88561) (PATCH ID: OSF520-645) ******** 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. HP has corrected this potential vulnerability. PROBLEM: (SE_G05218, 95182) (PATCH ID: OSF520-853) ******** This patch prevents vold from core dumping when attempting to delete a disk that was not initialized properly. An example stack trace from a core dump follows: thread 0x21 signal Segmentation fault at >*[__nxm_thread_kill, 0x3ff805bab48] ret zero, (ra), 1 (dbx) t > 0 __nxm_thread_kill 1 pthread_kill 2 (unknown)() [0x3ff805be96c] 3 (unknown)() [0x3ff807f369c] 4 exc_raise_signal_exception 5 (unknown)() [0x3ff805b5a9c] 6 delete_common 7 req_da_delete 8 request_loop() 9 main(argc = 3, argv = 0x11fffc018) PROBLEM: (95506) (PATCH ID: OSF520-951) ******** This patch fixes a deadlocking problem in the kernel where a file open on a clone could hang when ACLs are enabled. This problem is recognizable by a number of processes in the "U" state. PROBLEM: (94955) (PATCH ID: OSF520-870) ******** When setting gh_min_seg_size to a value of 4M, a message is printed at boot time stating: vm_configure: gh_min_seg_size too small or not aligned on 8meg boundary PROBLEM: (94104) (PATCH ID: OSF520-1083) ******** A call to setsockopt with a length > 4G may result in either or both a memory corruption error and a kmf. A kmf will have a call to setsockopt on the process causing the crash. PROBLEM: (95158) (PATCH ID: OSF520-882) ******** This is a fix for a problem where Smart Array 5300 Logical Volumes were counted as RAID controllers. The problem affected performance of system management utilites and could generate confusing error messages seen by system managers. Regular users were not affected by this problem. PROBLEM: (95977) (PATCH ID: OSF520-1112) ******** This patch fixes a situation in which a system with a SA5300 controller can experience a system hang or machine check crash dump when recovering from a controller lockup error or command timeout. PROBLEM: (95414) (PATCH ID: OSF520-958) ******** Sometimes when halting or rebooting a system that is currently using a DAPBA or DAPCA ATM adapter, the system will crash. This does not happen consistently; a system may reboot successfully many times without triggering this problem. If you are using DAPBA or DAPCA adapters, you should install this patch. PROBLEM: (95901) (PATCH ID: OSF520-1076) ******** On a system generating a heavy volume of audit events the "auditd -d" command which flushes the kernel audit buffers could cause audit data corruption on a multi-cpu machine. PROBLEM: (DSATP26SZ, HPAQC000P) (PATCH ID: OSF520-960) ******** This patch fixes a problem where two threads can hang in a deadlock. One thread hangs during the rename of an AdvFS file, while another thread hangs during a defragment (or rmvol, or balance, or migrate) in the same AdvFS domain. The stack traces of the deadlocked threads are similar to the following. Thread A: > 0 thread_block 1 lock_wait 2 lock_read 3 msfs_rename 4 cfs_comm_rename 5 cfs_rename 6 rename 7 syscall 8 _Xsyscall Thread B: 0 thread_block 1 lock_wait 2 lock_write 3 migrate_normal 4 migrate_normal_one_disk 5 mig_migrate 6 bs_migrate 7 msfs_syscall_op_migrate 8 msfs_real_syscall 9 msfs_syscall 10 syscall PROBLEM: (DSATD03BH) (PATCH ID: OSF520-1073) ******** This patch prevents a kernel memory fault panic in _OtsMove when going through the fs_read() routine. The panicing thread will have a stack trace similar to the following. 4 panic src/kernel/bsd/subr_prf.c : 1378 5 trap src/kernel/arch/alpha/trap.c : 2285 6 _XentMM src/kernel/arch/alpha/locore.s : 2219 7 _OtsMove src/kernel/arch/alpha/ots_move_alpha.s : 1592 8 uiomove src/kernel/bsd/kern_subr.c : 196 9 uiomove_frag src/kernel/msfs/fs/fs_read_write.c : 5486 10 fs_read src/kernel/msfs/fs/fs_read_write.c : 4651 11 msfs_read src/kernel/msfs/osf/msfs_vnops.c : 3446 12 vn_pread src/kernel/vfs/vfs_vnops.c : 1149 13 msfs_strategy src/kernel/msfs/osf/msfs_vnops.c : 6302 14 aio_rw src/kernel/bsd/kern_aio.c : 3225 15 syscall src/kernel/arch/alpha/syscall_trap.c : 725 16 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (95736) (PATCH ID: OSF520-1092) ******** This fix removes a compiler warning about an incorrect cast in AdvFS. PROBLEM: (DE_G06128) (PATCH ID: OSF520-1097) ******** This patch fixes potential crashes from within the pshared subsystem. PROBLEM: (88774) (PATCH ID: OSF520-1059) ******** The medium changer driver did not support the "manufacturer" EHM attribute thus information would be missing for example in a use of the "hwmgr -view devices" command. This is now corrected. PROBLEM: (95515) (PATCH ID: OSF520-984) ******** nissetup leaves /etc/group with the wrong mode of 600 after removing NIS. As a result, utilities that read /etc/group (like the group command) will be unable to retrieve group name information. PROBLEM: (84770, 86856, 95945) (PATCH ID: OSF520-1101) ******** PROBLEM: The cylinder summary area of UFS was created with a static capacity of 256k. This limits the total number of cylinder groups to 16384 which may be less than the number of cylinder groups required for a large file system of approximately 800gb or more. This can cause system panics when attempting to access data beyond cyl group 16K. PROBLEM: If a large capacity Memory File System is attempted, the command may produce a core dump if malloc() cannot allocate the requested memory size. PROBLEM: (95266, DETECTING) (PATCH ID: OSF520-871) ******** This patch adds two system configurable tunables: 'titan_sys_ps_hotswap' and 'titan_sys_fan_hotswap' to the ES45 platform. By default, these variables are set to 1. When this variable is set to 1 and a redundant power supply or redundant fan fails, the environmental monitoring subsystem will not report an error. When this variable is set to 0 and a redundant power supply or a redundant fan fails, the environmental monitoring system will report an error. PROBLEM: (95053) (PATCH ID: OSF520-896) ******** The maximum size of a property list name for files was inadvertently set to 245. This maximum name size has been increased to 255. PROBLEM: (70503) (PATCH ID: OSF520-956) ******** Earlier, certain default clean up cron jobs were scheduled for 2 a.m. These were skipped during the time change to DST. Now fixed this problem. PROBLEM: (95880) (PATCH ID: OSF520-1070) ******** A panic may be seen in bs_derefp during an I/O error. The problem arises because the I/O error was not being handled correctly. A sample crash may look like: 4 panic 5 trap 6 _XentMM 7 bs_derefpg 8 bmtr_scan_mcells 9 bmtr_get_rec_n_lk PROBLEM: (92587) (PATCH ID: OSF520-1044) ******** Changed a rws write lock in the VMAC lookup routine to a rws read lock for better SMP scaling. PROBLEM: (BCSMB00Z8/221-1-457, 95332) (PATCH ID: OSF520-900) ******** The code for mktime() (and related time routines) in libc was updated in V5.0 to support more robust time transition rules and new time zones around the world. This update introduced a regression from the pre-V5.0 mktime() behavior in the handling of potentially ambiguous tm structs (ie: those that fall within a backward clock shift & which have an initially negative tm_isdst value). The pre-V5.0 mktime() would favor the later end of such transitions. The V5.0 (and later) mktime() varied as to which end of the transition it would favor, due to a lack of intentional constraints for such cases. This patch adjusts the algorithm to favor the later end of such transitions and restores mktime() behavior consistent with pre-V5.0 systems. PROBLEM: (95437) (PATCH ID: OSF520-1090) ******** This patch fixes a cluster panic where a long running defragment thread was hogging the CPU and not letting an ICS thread run. When the ICS thread finally runs, it checks that it has not run in a very long time and panics the system. The fix is to add preemption points to the routine that copies the migrating pages and to its subordinates as well. PROBLEM: (95813) (PATCH ID: OSF520-1033) ******** This patch fixes a system panic. The problem is most likely to happen when system is under heavy load and low on memory. There are two possible panic strings. panic string: "mcs_lock: lock already owned by cpu" stack trace: 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1398 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2348 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 simple_lock_fault src/kernel/kern/lock.c : 2874 6 mcs_lock_state_violation src/kernel/kern/lock.c : 3170 7 vm_ops_reference_def src/kernel/vm/vm_object.c : 495 8 stack_alloc src/kernel/vm/vm_kmap.c : 988 9 thread_create_internal src/kernel/kern/thread.c : 1628 10 procdup src/kernel/vm/vm_unix.c : 893 11 newproc src/kernel/bsd/kern_fork.c : 1094 12 fork1 src/kernel/bsd/kern_fork.c : 902 13 fork src/kernel/bsd/kern_fork.c : 690 14 syscall src/kernel/arch/alpha/syscall_trap.c : 725 15 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 panic string: "thread_block: simple lock owned" stack_trace: 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1398 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2348 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 thread_block src/kernel/kern/sched_prim.c : 3096 6 thread_preempt src/kernel/kern/sched_prim.c : 5162 7 ubc_page_stealer src/kernel/vfs/vfs_ubc.c : 3794 8 vm_bigpg_alloc src/kernel/vm/vm_resident.c : 3096 9 vm_page_alloc src/kernel/vm/vm_resident.c : 2890 10 stack_alloc src/kernel/vm/vm_kmap.c : 1030 11 thread_create_internal src/kernel/kern/thread.c : 1628 12 procdup src/kernel/vm/vm_unix.c : 893 13 newproc src/kernel/bsd/kern_fork.c : 1094 14 fork1 src/kernel/bsd/kern_fork.c : 902 15 fork src/kernel/bsd/kern_fork.c : 690 16 syscall src/kernel/arch/alpha/syscall_trap.c : 725 17 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (221-1-931) (PATCH ID: OSF520-1023) ******** This patch fixes the problem encountered with the Bourne shell when a filename with trailing slash ("/") is used as an argument to the command. PROBLEM: (95337, 90640) (PATCH ID: OSF520-1110) ******** This problem causes tape devices that do not respond, possibly resulting in hung user tasks, or causes a kernel memory fault, usually involving null pointers in ctape_ioctl or ctape_done. PROBLEM: (94941, 92956, 93799) (PATCH ID: OSF520-818) ******** This patch fixes locking problems in advfs' msfs_getpage(), which could lead to hangs/panics. A sample thread hang: 0 thread_block() 1 lock_wait() 2 lock_read_to_write() 3 msfs_getpage() 4 u_vp_fault() 5 u_map_fault() 6 vm_fault() 7 trap() 8 _XentMM() 9 qcopy() 10 copyout() 11 uiomove() 12 fs_read() 13 msfs_read() 14 vn_read() 15 rwuio() 16 read() 17 syscall() 18 _Xsyscall() With lock debugging enabled: 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 printf() 4 panic() 5 lock_fault() 6 lock_read_to_write() 7 msfs_getpage() 8 u_vp_fault() 9 u_map_fault() 10 vm_fault() 11 trap() 12 _XentMM() 13 qcopy() 14 copyout() 15 uiomove() 16 fs_read() 17 msfs_read() 18 vn_read() 19 rwuio() 20 read() 21 syscall() 22 _Xsyscall() PROBLEM: (95197) (PATCH ID: OSF520-873) ******** This security related patch fixes a problem where the Home Directory and login shell attributes for a user account were not suppled to the audit daemon for authentication failures. HP has resolved this problem. PROBLEM: (nhd.storage_hw.002.lp10k) (PATCH ID: OSF520-1099) ******** Adds recognition for possible future devices. PROBLEM: (89979) (PATCH ID: OSF520-970) ******** Patch eliminates compiler warnings in 'ksh'. PROBLEM: (95049, TKT370920) (PATCH ID: OSF520-860) ******** This patch addresses three basic issues: 1) The TCP window has been increased from 96 KB to 500 KB for performance improvements. 2) This patch will have the netisr thread dynamically estimate the reply size and subsequently reserve the space in the socket buffer. 3) A new timeout check has been added to notice when the data hasn't been ACKnowledged in 30-50 seconds and copies those buffers. This will allow the UBC to free up those mbufs and not tie them up. PROBLEM: (95798) (PATCH ID: OSF520-1075) ******** When running Enhanced Security, an emergency login for the root account on the console would fail in TruCluster configurations with "Impossible to execute /sbin/sh". This could occur if the Enhanced Security databases are corrupt, or if the root account is disabled. The accompanying messages to indicate such an 'emergency' login would say "However, root login at terminal console is allowed." PROBLEM: (95751) (PATCH ID: OSF520-1088) ******** This patch provides a workaround for a domain panic when corruption in the deferred-delete list of an AdvFS filesystem is detected. Instead of panicking the domain, the DDL is truncated (potentially rendering some space on the disk unusable), but the system keeps running. The lost space can be recovered at a later time, when the domain is inactive, by running fixfdmn. PROBLEM: (95294) (PATCH ID: OSF520-890) ******** For sites which have either the /tmp or /var/tmp filesystem as a separate AdvFS domain, the nightly dirclean entries in root's crontab file previously generated error messages for failures to remove these entries. The /usr/sbin/dirclean utility no longer attempts to remove the .tags directory or the quota.group and quota.user files. (For UFS filesystems, dirclean will still remove a .tags directory normally.) PROBLEM: (AT_G04801) (PATCH ID: OSF520-847) ******** This correction prevents kmf's in AdvFS, by adding - validation of property list namelength and mcell record header size field - prevention against improper accesses to reserved files, including targetting them on setproplist and getproplist syscalls PROBLEM: (95474) (PATCH ID: OSF520-965) ******** This patch fixes a system panic in the ubc_page_stealer routine. The panic is caused by a lock timeout on the ubc_clru_lock. PROBLEM: (95352) (PATCH ID: OSF520-1047) ******** A kernel memory fault can occur which using the table syscall to retrieve the TBL_ARGUMENTS information. The panic is usually triggered by using the "ps" command. The stack trace: 0 boot src/kernel/arch/alpha/machdep.c : 2706 1 panic src/kernel/bsd/subr_prf.c : 1426 2 trap src/kernel/arch/alpha/trap.c : 2285 3 _XentMM src/kernel/arch/alpha/locore.s : 2219 4 _OtsZero src/kernel/arch/alpha/ots_zero_alpha.s : 404 5 table src/kernel/bsd/cmu_syscalls.c : 1800 6 syscall src/kernel/arch/alpha/syscall_trap.c : 725 7 _Xsyscall src/kernel/arch/alpha/locore.s : 1864 PROBLEM: (NETWK-856) (PATCH ID: OSF520-792) ******** Streamline kernel module functions PROBLEM: (66873, 80677, 80944, 89050, 89274, 91627, 94285) (PATCH ID: OSF520-901) ******** The getdate() function uses mktime() to normalize the tm struct being generated for it's input data. However, getdate() was not properly checking both the return value and errno for a potential out-of-range indication from it's mktime() call. This patch fixes this problem. The strptime() routine matches input incorrectly to the format string. According to the Single UNIX Spec for strptime(), "Any other conversion specification is executed by scanning characters until a character matching the next directive is scanned, or until no more characters can be scanned." Instead, the strptime() routine makes assumptions of how many characters to scan based on the number of digits in the maximum value for that particular conversion specification. This algorithm does not give consistent results and does not follow the Single UNIX Spec. This patch modifies the parsing algorithm to provide full compliance. The strptime() routine matches white space incorrectly to %n and %t. It matches white space up to the first tab character for %t and matches white space up to the first newline character for %n. The Single UNIX Spec for strptime defines both %n and %t as "is any white space". This patch fixes strptime() so it matches any white space to both %n and %t. The callrpc() routine tracks information related to an rpc call, including the socket used for communication and a valid field. If the valid flag is false, the code closes the socket. In some instances, this results in closing sockets not owned by the process. This patch modifies callrpc() to track whether or not the process has opened the socket. The socket is closed only if this field indicates that the socket is owned by the process. Uses of fork()/popen() can trigger "inconsistent order" violations whenever a fork() operation is used within Visual Threads. This patch fixes this problem. The strncasecmp() and strcasecmp() routines did not check the input parameters for NULL. Attempts to access the data through the NULL parameters resulted in seg faults. This patch fixes this problem by handling NULL parameters as special cases. The nacreate() routine in the libnuma library calls nmmap() and is supposed to return NULL if the call failed. The failure check was incorrectly coded and could result in a seg fault instead of the correct NULL return from nacreate(). This patch fixes the failure check from the nmmap() call in nacreate(), thus avoiding the potential seg fault. PROBLEM: (92864) (PATCH ID: OSF520-1089) ******** This patch fixes a cross-node cluster deadlock that can occur when AdvFS threads on two cluster nodes simultaneously call code that requires the taking of already held AdvFS locks on the other node. The symptom is a hang on at least two nodes of the cluster. Both nodes should have threads that include calls to ubc_rem_excess_pages() and cfscall_fsync() on the one hand and to cfs_comm_fsync() on the other. Possible stack traces on one node of the cluster are the following: ------- > 0 thread_block() ------- 1 sleep_prim ------- 2 mpsleep ------- 3 icscli_wait ------- 4 icstnc_cli_rcall ------- 5 tnc_rcall ------- 6 rcfscall_service ------- 7 rcfscall ------- 8 cfscall_fsync * ------- 9 cfs_putpage ------- 10 ubc_rem_excess_pages * ------- 11 ubc_page_alloc ------- 12 ubc_lookup ------- 13 bs_pinpg_one_int ------- 14 bs_pinpg_clone ------- 15 bs_pinpg ------- 16 lgr_writev_ftx ------- 17 log_donerec_nunpin ------- 18 ftx_done_urdr ------- 19 ftx_done_u ------- 20 odm_create_xtnt_rec ------- 21 overlay_xtnt_map ------- 22 switch_stg ------- 23 migrate_normal ------- 24 migrate_normal_one_disk ------- 25 mig_migrate ------- 26 bs_migrate ------- 27 msfs_syscall_op_migrate ------- 28 msfs_real_syscall ------- 29 msfs_syscall ------- 30 syscall ------- 31 _Xsyscall ------- > 0 thread_block ------- 1 lock_wait ------- 2 lock_write ------- 3 lgr_writev_ftx ------- 4 log_donerec_nunpin ------- 5 ftx_done_urdr ------- 6 ftx_done_n ------- 7 fs_fsync ------- 8 msfs_fsync ------- 9 cfs_comm_fsync * ------- 10 crfs_fsync_0 ------- 11 icstnc_rpc_dispatch ------- 12 icstnc_svr_rcall ------- 13 icssvr_daemon_from_pool The use of AdvFS utilities such as defragment or migrate on both cluster nodes may be more prone to cause the hang. PROBLEM: (94066) (PATCH ID: OSF520-812) ******** Volmigrate returns a shell error when attempting to migrate an AdvFS domain with multiple filesets. This has been fixed, and these domains can now be migrated as long as all the filesets are mounted. PROBLEM: (91618) (PATCH ID: OSF520-904) ******** When enhanced core file naming is on, an incorrect msg is printed when core umps. The message file has been modifed accordingly to correct this problem. PROBLEM: (63460) (PATCH ID: OSF520-971) ******** The cron daemon was not logging the commands it runs on the request of users, even when the loglevel is set to 4 in /var/adm/cron/queuedefs. This is because there was no support for this feature in cron. Now we have this support. PROBLEM: (95815, 94560, 94529) (PATCH ID: OSF520-1113) ******** In certain circumstances an IO may become permanently stalled if a previous close to that device occurred when the queue was stalled. PROBLEM: (BCGMS0LJC) (PATCH ID: OSF520-936) ******** This change fixes client (login, su, rshd, edauth, and sshd2) hangs and long delays under Enhanced Security, as well as some intermittent errors or failures seen with prpasswdd or rpc.yppasswdd. Of particular note are the following externally-visible changes. In a TruCluster environment, the prpasswdd and rpc.yppasswdd daemons now watch to see whether the CFS service for the /var filesystem is moved. If so, the active instance of the daemon will also migrate to the appropriate cluster member. The prpasswdd and rpc.yppasswdd daemons now monitor whether their start-up portmapper registrations disappear or otherwise become unavailable to their clients. If this happens, they attempt to re-register with the portmapper. This is done by having the child ('worker') process exit, and the parent ('monitor') process re-start it. Some syslog messages for the LOG_AUTH facility have been clarified, and some additional ones have been added for monitoring whether the rpc.yppasswdd or prpasswdd daemon is unresponsive. [The clients will log intermittent messages at level LOG_NOTICE, approximately at 50-second intervals, if they can't get responses from the daemons.] The rpc.yppasswdd and prpasswdd daemons now make a syslog entry to the LOG_AUTH facility at level LOG_NOTICE when they become active and start trying to service client requests. This is most useful in a cluster, since it helps to identify the 'active instance' of the relevant daemon. The prpasswdd daemon no longer leaves core files in / (the root directory). If it leaves a core dump at all (which now normally should only happen in response to a SIGQUIT signal), it will be found in the /var/tcb/files directory. It is still true that any attempt to manage the rpc.yppasswdd and prpasswdd daemons with signals should only be done with the child ('worker') processes, and not with the parent ('monitor') processes. The child processes are the ones which write their pids in the (member-specific) /var/run/rpc.yppasswdd.pid and /var/run/prpasswdd.pid files. Delivery of SIGINT or SIGTERM to one of the child processes causes a graceful exit, also terminating the parent process. Delivery of SIGUSR2 causes a graceful re-start of the child process. A SIGQUIT causes a re-start after a core dump. Finally, a SIGHUP causes the child to terminate, and the parent to re-exec itself with the same argument vector, which will then cause a re-start of the child process. This last case is to minimize the down-time for the daemons should future patches to them or to the libsecurity.so library be necessary. PROBLEM: (95016, KAOQ90167) (PATCH ID: OSF520-834) ******** This patch corrects mountd so those hosts specified in the continuation lines as part of the hostlist in "-root=hostlist" and "-rw=hostlist" to be able to mount properly. It also allow root users on those hosts to gain access to the directory with proper protection. PROBLEM: (90023, 93422) (PATCH ID: OSF520-1060) ******** All the members of a LAG set must operate at the same speed. Previously this has meant that DEGPA ("alt" driver) could not be used in a LAG set with DE50x ("tu" driver) or DE60x ("ee" driver) adapters. This patch modifies the behavior so that these adapters can be combined in a LAG set when they are operating at the same speed. PROBLEM: (37500) (PATCH ID: OSF520-935) ******** Patch makes start up scripts in /sbin/init.d world readable. PROBLEM: (SSRT2275) (PATCH ID: OSF520-922) ******** This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (95684) (PATCH ID: OSF520-1006) ******** PROBLEM: Panic CISS_STARTIO: JOB STRUCTUER SHOULD HAVE BEEN AVAILIBLE. If the following stack trace is seen in the crash dump, this patch should be loaded. 0 boot 1 panic 2 ciss_startio 3 ciss_scsiio 4 ciss_proc_deferred_list 5 ciss_deferred_ccb_thread PROBLEM: (95169, 95152) (PATCH ID: OSF520-833) ******** This patch helps improve scalability by o turning off the collection of some internal statistics o prefetching some data, by using locals to collect changes in two globals so that the globals only need to be modified once o rearranging the order of some instructions to get a better chance of being ready for our use when needed. PROBLEM: (95963) (PATCH ID: OSF520-1116) ******** This patch corrects a lockmode 4 problem in cdisk_event_notify. PROBLEM: (BCGMR1W76, SE_G05652) (PATCH ID: OSF520-940) ******** This patch prevents LSM commands from hanging in sosleep() An example stack trace: crash> st CPU: 6 PID: 674770 THREAD: fffffc10882cc000 COMMAND: "volstat" 1: sleep_prim+616: thread_block() 2: mpsleep+28: sleep_prim(0x0, 0x0, ???, 0x0, 0x0, 0x400) 3: sosleep+132: mpsleep(???, 0x0?, ???, 0x0?) 4: sosbwait+204: sosleep(0xfffffc10f21c1180, 0x0?, 0x11a, 0x0) 5: soreceive+2380: sosbwait() 6: soo_read+60: soreceive() 7: rwuio+212: soo_read(???, 0xfffffe08774f7838?) 8: read+80: rwuio() 9: syscall+592: read() 10: _Xsyscall+92: syscall(0x7ffc) 11: 0x3ff800cdad8: _Xsyscall( ) PROBLEM: (BCGMP29C5) (PATCH ID: OSF520-1048) ******** This patch fixes a problem where the system can panic with a "kernel memory fault" in simple_lock(), being called from fuser(). The problem being fixed is a race condition between a thread doing a fuser() syscall for a file, and another thread attempting to close that file. The following is the stack trace of the panicing thread. > 0 boot src/kernel/arch/alpha/machdep.c : 2672 1 panic src/kernel/bsd/subr_prf.c : 1401 2 trap src/kernel/arch/alpha/trap.c : 2273 3 _XentMM src/kernel/arch/alpha/locore.s : 2143 4 simple_lock src/kernel/arch/alpha/lockprim.s : 709 5 fuser src/kernel/svr4/kern_fuser.c : 561 6 syscall src/kernel/arch/alpha/syscall_trap.c : 725 7 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 PROBLEM: (DE_G05944, 95552) (PATCH ID: OSF520-992) ******** This patch fixes a possible, but rare hang in the hardware configuration subsystem. PROBLEM: (AT_G05769) (PATCH ID: OSF520-973) ******** This correction prevents a situation where an AdvFS Migrate syscall launched from the CFS client could result in a hung client thread and a hung server thread. The server thread would be sleeping in insert_actRange_onto_list(). PROBLEM: (95758) (PATCH ID: OSF520-1095) ******** The V1.11 ciss driver fixes the following panic. 0 stop_secondary_cpu(do_lwc = 0) 1 panic(s = 0xffffffff008c0580 = "event_timeout: panic request" 2 event_timeout 3 printf 4 panic(s = 0xffffffff0082cc58 = "thread_block: interrupt level call") 5 thread_block() 6 ciss_hw_rst_cmplt 7 ciss_ErrorRecovery 8 ciss_intr 9 _XentInt 10 idle_thread() PROBLEM: (95079) (PATCH ID: OSF520-814) ******** On a cluster, the following sequence of commands results in a system panic: # mfs -s 500 /mnt/mfs # cd /mnt/mfs # kill -9 "MFSPID"; sleep 1; cd; umount /mnt/mfs (The kill and the umount must be occur within 5 seconds of each other.) The panic stack may look like: (dbx) t 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 printf() 4 panic() 5 lock_fault() 6 lock_write() 7 dounmount() 8 mfs_mount_block() 9 cluster_mount() 10 mount1() 11 syscall() 12 _Xsyscall() PROBLEM: (BCGMD1WZP, 95753) (PATCH ID: OSF520-1039) ******** This patch fixes a problem where rmvol could go into an infinite loop while trying to move a file from a volume being removed to a new volume. This patch fixes a problem where information about a file could be lost while doing a rmvol. The most common types of information lost are fs_stat records which contains information about the type of file, size and creation times; ACLs (property lists) and directory indexes. PROBLEM: (95121) (PATCH ID: OSF520-886) ******** This patch fixes a ksh problem related to cleaning the process associated with control terminal when a login session is abruptly stopped. This problem occurs when trap(1) defined either in a startup script or a script executed within the current shell process. PROBLEM: (IT_G05939, CH_G05474, CH_G05475, BCGMC00BM, DEK088095, LU_G05635, DE_G05540, IT_G05434) (PATCH ID: OSF520-987) ******** The patch fixes a problem and prevents 'ccfg_MakeDeviceIdentWWID: Invalid device ID' messages from being generated when they should not be. PROBLEM: (95638) (PATCH ID: OSF520-997) ******** This is a cluster specific fix regarding a possible erroneous console warning during boot when cluster root is under LSM control. The console warning, WARNING: cluster root devices are on private buses! may erroneously appear when cluster root is under LSM control. This warning message indicates a device was accessed remotely to mount cluster root. When cluster root is under LSM control, the rootdg disk group is loaded early to start the cluster_rootvol volume. If the rootdg disk group includes disks that are not on shared storage, this message may appear as part of loading rootdg, even though the cluster_rootvol volume is using shared storage. This fix will suppress the erroneous console warning. LSM does not support such cluster root domain configurations where multiple cluster members must be available to mount cluster root. PROBLEM: (221-1-67) (PATCH ID: OSF520-823) ******** This patch fixes a problem which causes a hang in fcntl()/setflck(). Sample stack trace: (dbx) t > 0 thread_block() 1 sleep_prim() 2 mpsleep() 3 setflck() 4 fcntl() 5 syscall() 6 _Xsyscall() Note that the above stack can reflect a legitimate state. The hang corrected here resulted from a thread not getting appropriately woken. PROBLEM: (95347) (PATCH ID: OSF520-967) ******** When an original fileset is unmounted during the deletion of its clone fileset, zero as the fileset id is sent to the cluster so a kernel memory fault occurs. This fix sends the cluster the saved non-zero fileset id of the original fileset to prevent the kernel memory fault from being occurred. PROBLEM: (95046) (PATCH ID: OSF520-820) ******** A panic can occur when reading granularity hint memory from another process via the procfs interface. Typical stack trace as follows: 4 panic 5 trap 6 _XentMM 7 vm_handle_if_gran_hint 8 procfs_read 9 vn_read 10 rwuio 11 read 12 syscall 13 _Xsyscall PROBLEM: (95026, 93405) (PATCH ID: OSF520-1065) ******** Increased the default values for udp_ttl and tcp_ttl to 128 hops to avoid packets being timed out due to previously exceeding the router hop count. PROBLEM: (89799, 95765) (PATCH ID: OSF520-943) ******** This patch is for a minor change to the fwupgrade command to allow the specified firmware update image to be located on a BOOTP server in a connected network. PROBLEM: (93321, 87630, 93320, 86058) (PATCH ID: OSF520-976) ******** This patch fixes following problems in sh. o Service denial problem when a quoted here doc script is executed. o Problem with handling ELF files. o The shell variable $- not holding -C set option when it is turned on. o Printing broken characters when type builtin utility of sh is invoked in Japanese locale. PROBLEM: (95771, 95941) (PATCH ID: OSF520-1016) ******** Prior to this patch, the "bcm" driver would report a wild number of data overruns even when none have occurred. For example: # netstat -s -I bcm0 1414684 receive failures, reasons include: 1414684 data overruns The problem was that the driver was reading the wrong counter to obtain this number. The driver has been fixed to read the correct counter. Additionally this patch allows DEGX2-SA adapters to be recognized and used by the driver. PROBLEM: (94012) (PATCH ID: OSF520-946) ******** This patch fixes the Tru64 IDE/ATAPI driver's reset logic to prevent a kernel memory fault when booting and to properly detect and log all master and slave reset failures when the system is operational. First, during probing of the IDE bus by the Tru64 IDE/ATAPI driver some 3rd party ATAPI CDROMs respond as if they are both a master and a slave on the IDE bus when no slave is physically present on the bus. When this occurs during probing, the Tru64 IDE/ATAPI driver believes there are two devices on the bus and not one device responding as two. This leads to a kernel memory fault later in the boot process when the driver attempts to configure the missing slave device. Secondly, the Tru64 IDE/ATAPI driver does not properly detect or log all master or slave reset failures. A reset failure is caused by a drive's inability to pass its own device diagnostics, which is a good indication of a hardware problem in the device. PROBLEM: (HPAQC016X, DSATS0LHV, HPAQD0F3M) (PATCH ID: OSF520-999) ******** This patch fixes the error "icssvr_daemon_from_pool: invalid IPL 4......" PROBLEM: (91547) (PATCH ID: OSF520-899) ******** When two concurrent process tries to move a file, only one process will be able to "unlink" the original file. In case, if both the process completes simultaneously, only one of the process can unlink the file after moving it to the specified destination. Since, the errno is not checked while unlinking the file, both the process return from "mv" command without any error. This fix takes care of this situation. PROBLEM: (91303) (PATCH ID: OSF520-1028) ******** Removing or truncating large files on UFS can be slow. PROBLEM: (95311) (PATCH ID: OSF520-1086) ******** Large amounts of network traffic a netisr thread causes a livelock cpu. PROBLEM: (86997) (PATCH ID: OSF520-884) ******** Under certain conditions a devices inquiry data would be over written with 0's. This would cause the following error message to be written to the logs 'DDR - Warning: Device has no "name"'. On devices such as the HSG80 this could also result in I/O stalls, application errors, and possible system hangs. PROBLEM: (95039) (PATCH ID: OSF520-933) ******** On HSG80,cdisk_handle_pr_ccb was returning failure without properly returning the reason code. This resulted in the same device being retried on several path. This fix will return proper error code in case of hardware failure, which will eliminate unnecessary retires by higher layer. The failure caseis unit attention with ascq = Oxf002. PROBLEM: (63702, PROBLEM) (PATCH ID: OSF520-931) ******** The crontab entry of kind " * * 31 * * " was scheduled on wrong days for the months having only 30 days. Now this problem is fixed. PROBLEM: (DE_G05472) (PATCH ID: OSF520-949) ******** This patch fixes a problem where a device file, such as /dev/console, can become inaccessible, returning the error 'Bad File Number'. PROBLEM: (STL526315) (PATCH ID: OSF520-905) ******** The runtime loader reports that it was trying to free a null pointer and displays the following message: "/sbin/loader: Attempt to free null pointer". This patch fixes this problem. PROBLEM: (89544) (PATCH ID: OSF520-1056) ******** Changed ICMP redirect processing code so it does not create an invalid route for an invalid redirect. PROBLEM: (81917, 95245) (PATCH ID: OSF520-839) ******** This patch address 2 issues. 1) When file system is full (/var) and crontab is issued to edit the crontab entries, earlier it use to truncate the entries. Now it performs check on whether the new entries are copied before replacing the existing entries 2) If a file system is full and we are editing a file in 'vi', then there is a possibility that file gets truncated upon write operation. Now vi has been modified to handle this scenario by reserving the blocks required ahead. If it fails in reserving the blocks, it comes out with error without truncating the existing file. PROBLEM: (KAOQB0009, 96291) (PATCH ID: OSF520-1053) ******** This patch fixes a problem where defragment (or migrate, balance, or rmvol) threads can hang in ms_malloc() and overlay_xtnt_map() if many of these threads are active. The hanging threads will have stack traces similar to the following. Victim threads: 0 thread_block src/kernel/kern/sched_prim.c : 3223 1 lock_wait src/kernel/kern/lock.c : 855 2 lock_write src/kernel/kern/lock.c : 950 3 overlay_xtnt_map src/kernel/msfs/bs/bs_inmem_map.c : 3869 4 switch_stg src/kernel/msfs/bs/bs_migrate.c : 3669 5 migrate_normal src/kernel/msfs/bs/bs_migrate.c : 1895 6 migrate_normal_one_disk src/kernel/msfs/bs/bs_migrate.c : 1336 7 mig_migrate src/kernel/msfs/bs/bs_migrate.c : 1111 8 bs_migrate src/kernel/msfs/bs/bs_migrate.c : 994 9 msfs_syscall_op_migrate src/kernel/msfs/bs/bs_misc.c : 6078 10 msfs_real_syscall src/kernel/msfs/bs/bs_misc.c : 3763 11 msfs_syscall src/kernel/msfs/osf/msfs_syscalls.c : 145 12 syscall src/kernel/arch/alpha/syscall_trap.c : 725 13 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 Culprit thread: 0 thread_block src/kernel/kern/sched_prim.c : 3223 1 malloc_internal src/kernel/bsd/kern_malloc.c : 2309 2 _ms_malloc src/kernel/msfs/bs/ms_mode.c : 178 3 imm_extend_xtnt_map src/kernel/msfs/bs/bs_inmem_map.c : 644 4 imm_copy_xtnt_descs src/kernel/msfs/bs/bs_inmem_map.c : 1599 5 imm_overlay_xtnt_map src/kernel/msfs/bs/bs_inmem_map.c : 4723 6 migrate_normal_one_disk src/kernel/msfs/bs/bs_migrate.c : 1278 7 mig_migrate src/kernel/msfs/bs/bs_migrate.c : 1111 8 bs_migrate src/kernel/msfs/bs/bs_migrate.c : 994 9 msfs_syscall_op_migrate src/kernel/msfs/bs/bs_misc.c : 6078 10 msfs_real_syscall src/kernel/msfs/bs/bs_misc.c : 3763 11 msfs_syscall src/kernel/msfs/osf/msfs_syscalls.c : 145 12 syscall src/kernel/arch/alpha/syscall_trap.c : 725 13 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 PROBLEM: (95536) (PATCH ID: OSF520-1029) ******** This patch corrects a NIS client hang sometimes seen when trying to connect with some third party NIS servers that only support the V2 NIS protocol. PROBLEM: (95596) (PATCH ID: OSF520-1005) ******** This patch fixes a problem where the CAM I/O subsystem does not always zero the Cam Control Blocks which are used by the peripheral drivers. This can cause a kernel memory fault or system hang when the subsystem is low on memory. The Cam Control Blocks which are not zeroed are allocated from a look-aside list at elevated IPL when there is no memory available in the regular pool. PROBLEM: (94877) (PATCH ID: OSF520-825) ******** This patch allows AdvFS to record if a domain panic has occurred, even if a system panic results. Without this patch, the system logs would need to be searched to gather this information. PROBLEM: (93358) (PATCH ID: OSF520-889) ******** Volsave would complain that the configuration had changed during saving when nothing else was going on. This change allows for synchronization for a couple vold requests. It will make sure volsave as well as other commands are more cluster safe and all synched up. PROBLEM: (94586) (PATCH ID: OSF520-895) ******** On a panic, the OS should halt and take a crash dump which can then be used to ascertain the cause of the panic. In some instances, the OS will automatically reboot instead of halting and will not take a crash dump. The console output will resemble the following: root@grouse-qa3> panic (cpu 0): rm_poll_for_panic_request: syncing disks... rebooting.... (transferring to monitor) halted CPU 1 halted CPU 2 halted CPU 3 halted CPU 0 halt code = 5 HALT instruction executed PC = fffffc00006a1a30 CPU 0 booting resetting all I/O buses (boot dga1.1001.0.3.1 -flags A) dga1.1001.0.3.1 is not connected failed to open dga1.1001.0.3.1 (boot dga1.1002.0.3.1 -flags A) block 0 of dga1.1002.0.3.1 is a valid boot block reading 19 blocks from dga1.1002.0.3.1 bootstrap code read in PROBLEM: (93291, 93291) (PATCH ID: OSF520-869) ******** This patch address the problem of two very small memory leaks when a CPU attribute changes or when a power state changes. The memory leak is several bytes and it is expected that these events occur infrequently. PROBLEM: (67870) (PATCH ID: OSF520-932) ******** This patch eliminates the compiler warnings in ksh. PROBLEM: (70547) (PATCH ID: OSF520-927) ******** By default, mfs() assigns a mode of 1777 to the root directory (or mount point). In some instances, this provides an opportunity for a user to access the directory before an administrator changes the mode to a more secure one. A command line option (-M ) has been added to mfs() the will allow the mode of the root directory to be set at the time the mfs file system is mounted. PROBLEM: (82393, MGO90408A) (PATCH ID: OSF520-1031) ******** This patch fixes a problem caused when the Tru64 TCP layer prematurely closes a slow, but good connection with TCP reset. An example is when a Networker backup stalls while the server has to reload a tape. PROBLEM: (93337) (PATCH ID: OSF520-1061) ******** This patch fixes a potential Kernel Memory Fault in the IPv6 subsystem. The problem occasionally occurs when ICMP v6 error messages are generated in response to IPv6 packets containing unknown options or packets too big for the MTU in case of forwarding. PROBLEM: (95630) (PATCH ID: OSF520-1014) ******** This patch fixes sh problem while executing a here document through command substitution. PROBLEM: (95174) (PATCH ID: OSF520-838) ******** This patch corrects a locking problem with NFS running over UFS. A code path had been introduced which failed to take the proper locks. The missing lock was to protect specific fields within the on-disk inode. This problem could show as either a data corruption or a system panic. PROBLEM: (95337) (PATCH ID: OSF520-985) ******** This problem causes a kernel memory fault with a stack trace that includes ctape_ioctl or ctape_generic_passthru and partially or non-initialized translation or path structure. PROBLEM: (95021, ZPOQCA010, 'cfs_stop_server_accept:) (PATCH ID: OSF520-879) ******** This patch prevents a panic that may occur in a cluster when a fileset mounted -o dual is failed over or unmounted during shutdown. Typical stack trace: > 0 stop_secondary_cpu src/kernel/arch/alpha/cpu.c : 1339 1 panic src/kernel/bsd/subr_prf.c : 1296 2 event_timeout src/kernel/arch/alpha/cpu.c : 2227 3 printf src/kernel/bsd/subr_prf.c : 981 4 panic src/kernel/bsd/subr_prf.c : 1353 5 cfs_stop_server_accept src/kernel/tnc_common/tnc_cfe/cfs_reloc.c : 1272 6 cms_handle_send_msg src/kernel/tnc_common/tnc_cfe/cms_kgs.c : 3728 7 cms_kgs_callback_thread src/kernel/tnc_common/tnc_cfe/cms_kgs.c : 3303 The panic string is: "cfs_stop_server_accept: error setting domain relocating flag" PROBLEM: (95765) (PATCH ID: OSF520-1013) ******** PROBLEM: The console device boot string is being incorrectly calculated for devices on subbordinate buses in PCI-based systems. When using consvar to set a console boot environment variable to a device on a subbordinate bus, the hose and bus numbers are incorrectly calculated and consvar fails. PROBLEM: When using consvar to display a console boot environment variable, one garbage character may appear at the end. PROBLEM: (91711, 94162) (PATCH ID: OSF520-1094) ******** This patch resolves a problem with sending multicast datagrams when no default or explicit multicast route is present. The datagram is sent through an interface specified through IP_ADD_MEMBERSHIP socketoption. The patch also addresses internet protocol conformance problems with respect to valid source addresses that can be used in datagrams. According to Internet Protocol specification RFC 1122, Loopback, Multicast, and Broadcast addresses are not allowed as source addresses. PROBLEM: (FR_G02937, DEK072506) (PATCH ID: OSF520-991) ******** This patch resolves a problem where some de50x network interface cards, under specific circumstances, may not send gratuitous arp packets . PROBLEM: (93237) (PATCH ID: OSF520-1030) ******** This patch clarifies the "LIDs do not match" error message. The binary error log now contains the values that do not match. The intent is to assist system managers or service personnel with troubleshooting. The command 'uerf -o full" displays the content of the binary error log in a human readable format. The error record with the message: "LIDs do not match (nn vs mm) - Removing PATH to device" also contains information about the Bus, Target and Lun of the offending device. Make sure to report all these numbers to support personnel. It could be helpful in determining why this error message was displayed. PROBLEM: (94782) (PATCH ID: OSF520-1111) ******** This patch fixes library dependencies to allow 'ifconfig' to be run in single user mode. PROBLEM: (DSATP17S6) (PATCH ID: OSF520-977) ******** This patch fixes a very slow boot when booting several cluster nodes at the same time and CLSM is configured. PROBLEM: (93044) (PATCH ID: OSF520-841) ******** PROBLEM (93044) (PATCH ID: ) A small timing window exist that could result in an I/O being returned with a good status if an attempt is made to abort the I/O during a bus or device reset. This fix patch prevents an abort from being issued by the driver during a reset and thus preserving the correct status of the I/O. PROBLEM: (TKT400347) (PATCH ID: OSF520-859) ******** This patch prevents an incorrect timestamp from being written to the time of year (TOY) clock on boot. PROBLEM: (95715) (PATCH ID: OSF520-1020) ******** Attempts to use IPV6_UNICAST_HOPS socket option on a raw IPv6 socket result in an EINVAL error code returned to the application. PROBLEM: (95378) (PATCH ID: OSF520-1051) ******** - In the original design, as soon as a cluster member receives the last fragment and figures that it has not received the complete set of fragments yet. It immediately starts the process of querying all cluster member to gather missing fragments. This posts a performance problem in case the remote node is a Linux system which sends fragments in reverse order. The cluster interconnect is stressed out heavily. A side problem with this design is that it only does fragment gathering once. If the other fragments arrive a different members after the last fragment arrives to a particular node, they will not be recovered. PROBLEM: (94741) (PATCH ID: OSF520-938) ******** The AdvFS migration code, on a clustered system, needs to ensure that pages are flushed before they are invalidated following the migration. This fix ensures that this is done. PROBLEM: (91927, 95450) (PATCH ID: OSF520-885) ******** PROBLEM: on EV6 systems, removing execute permission from memory may not take effect immediately. No typical stack trace, no potential for panic. PROBLEM: If a set of kernel virtual addresses at the high end of virtual memory are unmapped, the system may panic with "delete_pv_entry: mapping not in pv_list". The failure can be identified with the following stack trace: 1 panic src/kernel/bsd/subr_prf.c : 1325 2 event_timeout src/kernel/arch/alpha/cpu.c : 2341 3 printf src/kernel/bsd/subr_prf.c : 1008 4 panic src/kernel/bsd/subr_prf.c : 1382 5 delete_pv_entry src/kernel/arch/alpha/pmap.c : 2496 6 pmap_remove_range src/kernel/arch/alpha/pmap.c : 3389 7 pmap_remove src/kernel/arch/alpha/pmap.c : 3588 8 anon_remap src/kernel/vm/vm_anon.c : 1412 9 anon_grow src/kernel/vm/vm_anon.c : 1126 10 u_anon_grow src/kernel/vm/u_mape_anon.c : 5414 11 u_map_entry_grow src/kernel/vm/vm_umap.c : 1424 12 u_map_enter src/kernel/vm/vm_umap.c : 1490 13 u_anon_create src/kernel/vm/u_mape_anon.c : 1558 14 smmap src/kernel/bsd/kern_mman.c : 1309 15 syscall src/kernel/arch/alpha/syscall_trap.c : 725 PROBLEM: (85929) (PATCH ID: OSF520-1066) ******** /sbin/init.d/route script was causing routes to not get flushed properly. PROBLEM: (95264, SSRT2412) (PATCH ID: OSF520-1012) ******** A potential security vulnerability has been discovered that may result in a denial of service (DoS) on RPC-based HP Tru64 UNIX servers with Enhanced Security (C2) enabled. This potential security vulnerability may be in the form of local and remote security domain risks. SSRT2412 portmapper with Enhanced Security (C2)enabled (Severity - High) PROBLEM: (LACCOL004) (PATCH ID: OSF520-948) ******** This patch corrects the problem of a possible panic in audit_rec_build when auditing execve with the exec_argp or exec_envp audit style enabled. PROBLEM: (DE_G05043, 94939) (PATCH ID: OSF520-1001) ******** This patch adds a lock to the initialization of a private client to avoid hung file system threads when the MVFS ClearCase filesystem is in use. PROBLEM: (95048) (PATCH ID: OSF520-989) ******** The patch fixes a process hang problem in ubc_common_lookup. Sometime, the process may loop forever trying to retry IO on a failed disk, when it receives "Not Ready" message. The fix will allow it to fail the io after few retries. PROBLEM: (92087, 95809) (PATCH ID: OSF520-1022) ******** This patch address the below problems with mv command. * mv fails when operated on running binaries. * mv doesn't allow a file rename even though directory permissions allows to rename. PROBLEM: (90225, 90332) (PATCH ID: OSF520-1021) ******** If a DE5xx adapter using auto-negotiation is brought down and back up (ie. ifconfig tu0 down; ifconfig tu0 up), it will not successfully re-negotiate and the interface will not work properly. This problem can be worked around by turning auto-negotiation off and back on again: lan_config -itu2 -a0 -s100 -x1 # switch auto negotiate OFF lan_config -itu2 -a1 -s100 -x1 # switch auto negotiate back ON This patch fixes this problem so that the work-around is no longer necessary. This patch also fixes the tu error counters so that reasons are listed for every transmit or receive failure. PROBLEM: (95878) (PATCH ID: OSF520-1079) ******** On a single cpu machine the system hangs until a reboot occurs. On a multi cpu machine that process continue to run consuming an entire cpu for a cluster member this could cause an ics_unable_to_make_progress: input thread stalled panic or force the customer to reboot the system PROBLEM: (93270) (PATCH ID: OSF520-1106) ******** This patch corrects the default parameter for physio_max_coalescing to 8k. PROBLEM: (87139, 84758, 86349, 95243) (PATCH ID: OSF520-1100) ******** This patch corrects problems in UFS extendfs functionality which could cause filesystem metadata inconsistency. Prior to this patch, UFS used a fixed sized cylinder summary area. It was possible for a filesystem's requirements to exceed the size of this cylinder summary area should the filesystem have more that 16K cylinder groups. Accessing the cylinder summary data for a cylinder group beyond the 16K limit could result in a system panic. One sample trace: 4 panic 5 trap 6 _XentMM 7 blkpref 8 ufs_ubcbmap 9 ufs_getapage 10 ufs_getpage 11 ufs_rwip 12 ufs_write 13 vn_write 14 rwuio 15 write 16 syscall 17 _Xsyscall This patch also corrects problems of using excessive memory for UFS cylinder summary data, and writing superblocks synchronously when asynchronous operations are sufficient. PROBLEM: (95230) (PATCH ID: OSF520-892) ******** System panics with "ialloc: dup alloc". Possible stack trace: > 0 stop_secondary_cpu() ["../../../../src/kernel/arch/alpha/cpu.c":1339, 0xff 1 panic() ["../../../../src/kernel/bsd/subr_prf.c":1296, 0xfffffc00002a1b04] 2 event_timeout() ["../../../../src/kernel/arch/alpha/cpu.c":2227, 0xfffffc0 3 printf() ["../../../../src/kernel/bsd/subr_prf.c":981, 0xfffffc00002a0e08] 4 panic() ["../../../../src/kernel/bsd/subr_prf.c":1353, 0xfffffc00002a1c74] 5 ialloc() ["../../../../src/kernel/ufs/ufs_alloc.c":623, 0xfffffc00005b1fa8 6 maknode() ["../../../../src/kernel/ufs/ufs_vnops.c":5153, 0xfffffc00005c96 7 ufs_create() ["../../../../src/kernel/ufs/ufs_vnops.c":1903, 0xfffffc00005 8 vn_open() ["../../../../src/kernel/vfs/vfs_vnops.c":765, 0xfffffc00005ff3a 9 copen() ["../../../../src/kernel/vfs/vfs_syscalls.c":3582, 0xfffffc00005eb 10 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":732, 0xfffff 11 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1814, 0xfffffc00 PROBLEM: (95682, 95733, SSRT2439, SSRT2341) (PATCH ID: OSF520-1007) ******** In certain conditions a too-small buffer could be allocated. Similarly, under certain circumstances, pointers to a buffer within the RPC subsystem could be set beyond the buffer's bounds. This patch fixes these problems. PROBLEM: (95168) (PATCH ID: OSF520-827) ******** In some cases, a process waiting on a semaphore is instructed to wake up (by another process) but the kernel does not deliver the wake up. The waiting process, therefore, waits "forever". If you think that you are experiencing this problem perform the following 3 step process: 1. create a file called "ipc_config" that contains the following: ipc: sem_broadcast_wakeup=1 2. As root, configure the system with the above using the sysconfigdb command: sysconfigdb -a -f ipc_config ipc 3. reboot the system If this solves your problem, apply this patch and remove the ipc configuration entry described above. Failure to remove this configuration parameter MAY in some cases cause a performance loss. PROBLEM: (93841) (PATCH ID: OSF520-824) ******** QARUN quota test on UFS sometimes fails due to "quot -v" returning wrong quota information. This can be seen by customers who runs "quot -v" on a UFS filesystem. "quot -v" may report that some users have less file blocks that have not been accessed for 30, 60, and 90 days. PROBLEM: (95001) (PATCH ID: OSF520-891) ******** Memory leaks are avoided in bourne shell. PROBLEM: (94036) (PATCH ID: OSF520-861) ******** When running in lockmode 0 (which is normal for uniprocessor machines), the locking package ended up patching out the wrong routine. This led to a_lock related panics. PROBLEM: (HPAQP2FLS) (PATCH ID: OSF520-986) ******** This patch fixes a problem where an I/O error (EIO) can occassionally be returned after a page fault. No errors appear in the binary.errlog file. When this occurs using Oracle 10i, the following error messages may appear on your screen: ORA-19755, ORA-19750, and ORA-27047, as well as the message "Tru64 UNIX Error: 5: I/O error". PROBLEM: (AT_G05679) (PATCH ID: OSF520-868) ******** Corrections to netstat and ifconfig so that when a MAC address is printed, it is printed using 2-digit hex octets with leading zeros. PROBLEM: (95223, 95254, 95760, 96063) (PATCH ID: OSF520-919) ******** PROBLEM: This problem can occur when any process is writing a large, sequential, file to disk. There are two system tunables (vm_ubcseqpercent and vm_ubcseqstartpercent) that are supposed to restrict sequentially accessed files from consuming too much of the UBC. These tunables were not being strictly enforced and could be ignored if a large amount of data was written very quickly, thus allowing a file to use more of the UBC than the user had specified. PROBLEM: This problem causes the system to be unresponsive when in low memory situations. If there is a lot of I/O being created on a system, and it is low on memory, it can become unresponsive to user commands. Attempts to execute a command will appear to hang but will execute eventually given enough time. PROBLEM: (95824) (PATCH ID: OSF520-1038) ******** the class scheduler fails to restart with the error "class_open: allocate or access semaphore Invalid argument" After a sysadmin deletes system owned (class scheduler) semaphores vi ipcrm -s. PROBLEM: (DE_G05962) (PATCH ID: OSF520-1050) ******** This patch fixes a problem where a cluster member can panic with a kernel memory fault in kdm_isenabled(). The panic can happen when a write to a file fails due to a "file system full" condition, if that file has an improperly initialzed recycled vnode. The stack trace of the panicing thread follows. 4 panic src/kernel/bsd/subr_prf.c : 1353 5 trap src/kernel/arch/alpha/trap.c : 2273 6 _XentMM src/kernel/arch/alpha/locore.s : 2143 7 kdm_isenabled src/kernel/dmapi/kdm_core.c : 4320 8 kdm_enospc_event src/kernel/dmapi/kdm_core.c : 4391 9 msfs_write src/kernel/msfs/osf/msfs_vnops.c : 3482 10 cfs_comm_write src/kernel/tnc_common/tnc_cfe/alpha/cfs_server.c : 3662 11 cfs_pfscachewrite src/kernel/tnc_common/tnc_cfe/alpha/cfs_vm_alpha.c : 2292 12 cfs_write src/kernel/tnc_common/tnc_cfe/cfs_vm_osi.c : 1611 13 vn_write src/kernel/vfs/vfs_vnops.c : 1474 14 rwuio src/kernel/bsd/sys_generic.c : 2264 15 write src/kernel/bsd/sys_generic.c : 2186 16 syscall src/kernel/arch/alpha/syscall_trap.c : 725 17 _Xsyscall src/kernel/arch/alpha/locore.s : 1814 PROBLEM: (95529) (PATCH ID: OSF520-925) ******** PROBLEM: a kernel memory fault panic occurs in the audcntl routine (kern_auditcalls.c) the first time the audit daemon attempts flush its kernel buffers to the audit log at user selected frequency (auditd -d freq). This problem may also occur when the audcntl syscall GET_DATALEN function is used from a privileged user id. PROBLEM: (95298) (PATCH ID: OSF520-980) ******** This patch updates the camreport program to recognize additional status. PROBLEM: (81454, 93085) (PATCH ID: OSF520-809) ******** This patch fixes an IDE/ATA bus hang caused by attempting to complete raw odd byte DMA transfers to/from IDE/ATAPI devices. The IDE/ATAPI specifications do no permit odd aligned or odd length DMA transfers to IDE/ATAPI devices. However, the IDE driver uses CAM scatter-gather lists, which are common to all devices under the CAM subsystem, to complete odd and even DMA transfers. These buffers can be of odd length or odd address alignment if an IO request is made for an odd amount of data. The discrepency between the CAM lists used by the IDE driver and the IDE/ATAPI specification causes the IDE driver to hang the IDE bus when attempting to complete raw odd byte or odd aligned DMA data transfers with IDE/ATAPI devices. PROBLEM: (BCPMR172K) (PATCH ID: OSF520-964) ******** This patch fixes a performance problem where threads could spend a long time in the check_busy() AdvFS routine. PROBLEM: (95865) (PATCH ID: OSF520-1069) ******** Packets on DLI interfaces were limited to 5000 bytes when sending and 10000 bytes when recieving. This didn't allow full-size jumbo packets (9000 bytes) to be successfully sent. This patch introduces two new global DLI tunables, sendspace and recvspace, to allow the system administrator to set appropriate limits for each system. The default limits were both increased to 16KB (16384 bytes), which should be sufficient for most systems. PROBLEM: (95612) (PATCH ID: OSF520-1027) ******** When a multithreaded process forks a single threaded process it | left some data in the proc structure that could cause problems. These problems were reported against the c-shell. PROBLEM: (94136, 95831, SSRT2275) (PATCH ID: OSF520-924) ******** This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (92275) (PATCH ID: OSF520-881) ******** ARP request for a permanent ARP entry is ignored, user cannot connect from remote system. Using non-permanent ARP works fine. The ARP request packet was inadvertently dropped, so no reply was sent. Fixed by not dropping ARP request packets, only ARP reply packets. PROBLEM: (95085, SSRT2384) (PATCH ID: OSF520-872) ******** A potential security vulnerability has been discovered in the HP Tru64 UNIX operating system that may result in a Denial of Service (DoS). This potential vulnerability may be in the form of local and remote security domain risks. The following potential security vulnerability has been corrected: SSRT2384 rpc (Severity - High) PROBLEM: (95134) (PATCH ID: OSF520-831) ******** This patch improves the scalabilty and performance of AdvFS. The patch accomplishes this by being smarter about when it needs a particular AdvFS lock and when it does not. PROBLEM: (92687, 93735) (PATCH ID: OSF520-840) ******** This patch contains two fixes. The first fix is for Tru64 nfs client panic when the client receives a null entry as a response to a readdirplus request from the Tru64 nfs server. The second fix is for a Tru64 nfs server panic caused by receiving illegal file access mode from the Tru64 nfs client. PROBLEM: (95595) (PATCH ID: OSF520-942) ******** I/O errors could result in a "blkfree: freeing free block" panic. Possible stack trace: > 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 printf() 4 panic() 5 blkfree() 6 itrunc() 7 ufs_inactive() 8 vrele() 9 ufs_remove() 10 unlink() 11 syscall() 12 _Xsyscall() PROBLEM: (95495) (PATCH ID: OSF520-1037) ******** This patch corrects a race condition that may result in hung disks, for example, after a SCSI reset is done. PROBLEM: (94368) (PATCH ID: OSF520-961) ******** This patch prevents an IDE bus hang caused when issuing a play audio track command from scu to an ATAPI CDROM containing an enhanced CD. An enhanced CD is a multisession disc with the first session containing audio tracks and a second session containing data tracks. Some ATAPI CDROMs do not correctly report an error to the Tru64 IDE/ATAPI driver when a play audio command is issued on the data portion of these discs. This can lead to an IDE bus hang, requiring a power cycle on the system. PROBLEM: (95711) (PATCH ID: OSF520-1009) ******** This patch fixes an internal problem in the kernel's advfs, ufs and nfs filesystems where extended attributes with extremely long names, greater than 247 characters, could not be set on files. The new limit is 254 + a Null string terminator. PROBLEM: (91112) (PATCH ID: OSF520-855) ******** This patch corrects interoperability problems with the libsshrcmd.so library or any threaded library that uses the rcmd function. PROBLEM: (BCSMM2J85, 94958) (PATCH ID: OSF520-857) ******** Fix a standards violation, as it causes ENOSPC for writes that previously returned EOK to their callers (standards require that writes that will fail due to ENOSPC should return such indication immediately to the caller). PROBLEM: (95277) (PATCH ID: OSF520-858) ******** If an error is found while trying to reset the AdvFS on disk state, a panic would occur. Since this error is really a problem with one domain and not a system problem, AdvFS now panics the domain instead of crashing the system. PROBLEM: (89000) (PATCH ID: OSF520-1026) ******** mv will fail to move a directory properly if the source directory ends in a trailing '/'. Example: $ mv foo/ bar/ ( where foo and bar are empty directories) Unable to unlink bar/. PROBLEM: (95799) (PATCH ID: OSF520-1074) ******** If a domain panic is encountered when in bmt_free_bf_mcells_i(), that is, AdvFS is freeing appropriate chained mcells, when you try to unmount the paniced domain, umount will hang. This path prevents that hang. > 0 thread_block src/kernel/kern/sched_prim.c : 3102 1 thread_sleep src/kernel/kern/sched_prim.c : 2691 2 _cond_wait src/kernel/msfs/bs/ms_generic_locks.c : 711 3 _ftx_start_i src/kernel/msfs/bs/ftx_routines.c : 974 4 quota_deactivate src/kernel/msfs/fs/fs_quota.c : 3465 5 msfs_unmount src/kernel/msfs/osf/msfs_vfsops.c : 3882 6 dounmount src/kernel/vfs/vfs_syscalls.c : 2127 7 unmount src/kernel/vfs/vfs_syscalls.c : 1934 8 syscall src/kernel/arch/alpha/syscall_trap.c : 713 9 _Xsyscall src/kernel/arch/alpha/locore.s : 1785 PROBLEM: (95440) (PATCH ID: OSF520-998) ******** PROBLEM: audit_tool when printing out execve audit events in brief mode (-B) may append nonsense characters to the output, example: # audit_tool `auditd -dq` -e execve -B AUID:RUID:EUID PID RES/(ERR) EVENT -------------- --- --------- ----- 0:0:0 697 0x0 execve ( /usr/sbin/auditmask M-4M-^?^C ) 0:0:0 697 0x0 execve ( /sbin/ls M-mM-^A ) 0:0:0 697 0x0 execve ( /usr/sbin/auditd ) 0:0:0 697 0x0 execve ( /usr/sbin/audit_tool M-1M-4M-|^C ) 0:0:0 697 0x0 execve ( ./audit_tool ) 0:0:0 697 0x0 execve ( /usr/sbin/auditmask M-4M-^?^C ) PROBLEM: (95126) (PATCH ID: OSF520-862) ******** This patch prevents segmentation faults when sia_ses_init is passed a malformed argument vector. This problem was discovered when dxchpwd was passed several -x arguments. The Motif libraries modified the argument vector during intialization. This modified vector eventually caused a segmentation fault in SIA initialization. PROBLEM: (93526) (PATCH ID: OSF520-832) ******** This patch fixes problem while expanding positional parameters in bourne shell. The expansion "$@" should generate zero fields when there are no positional parameters specified for the shell function. PROBLEM: (87748) (PATCH ID: OSF520-911) ******** During the btcreate of the filesystems with LSM on, some of the files will be created under /usr/lib/sabt/etc. Since these files are not deleted, while dumping the filesystems, these files too get dumped on the tape. At the time of extraction,these files are restored as if they were archived by btcreate. This is avoided by removing these file before they are dumped on to the tape. PROBLEM: (95608) (PATCH ID: OSF520-1062) ******** rdg_unwire_iodesc() panics with the message "rdg: unwiring". The address at which RDG attempted to unwire (calling vm_map_pageable()) is not part of any vm_map_entry. This is only seen when using gh_chunks/rad_gh_regions. The cause is that wires were improperly recorded, thus allowing shmdt() to succeed when it should have returned an error. The next time RDG attemps to wire the memory, it cannot find it and panics. PROBLEM: (SSRT2275) (PATCH ID: OSF520-888) ******** Chatr (Change Attribute) is a new tool which can enable or disable execution from data (stack or heap) by changing a binary's file attribute. This patch provides protection against a class of potential security vulnerabilities called buffer overflows. Buffer overflows are sometimes exploited in an attempt to subvert the function of a privileged program and possibly execute commands at the elevated privileges if the program file has the setuid privilege. This patch allows a system administrator to enable memory management protections that limit potential buffer overflow vulnerabilities. PROBLEM: (95509) (PATCH ID: OSF520-1139) ******** Under some circumstances, a system may panic with a kernel memory fault when a device that is being opened by one program is being deleted via the "hwmgr" utility. The stack trace will have an open routine (often character special) and hwc_get_devinfo() will be calling hwc_lookup_devt_safe(). PROBLEM: (96301) (PATCH ID: OSF520-1177) ******** Fixes a potential panic in the auditing of the swapctl syscall. 0 boot 1 panic 2 trap 3 _XentMM 4 audit_rec_build 5 swapctl 6 syscall 7 _Xsyscall PROBLEM: (62299) (PATCH ID: OSF520-1121) ******** PROBLEM: When write and pwrite were used in conjuction with the O_SYNC flag they would return SUCCESS even if the disk was physically removed from the system. The new code checks for the O_SYNC or O_DSYNC flag, and if set, any error in putting data to disk is reported. PROBLEM: (96333, SSRT2323) (PATCH ID: OSF520-1193) ******** Fix to close a security hole described in SSRT2323. I have included the relevant exerpts below. II. Problem Description A few system calls were identified that contained assumptions that a given argument was always a positive integer, while in fact the argument was handled as a signed integer. As a result, the boundary checking code would fail if the system call were entered with a negative argument. III. Impact The affected system calls could be called with large negative arguments, causing the kernel to return a large portion of kernel memory. Such memory might contain sensitive information, such as PROBLEM: (96357) (PATCH ID: OSF520-1180) ******** This patch allows the system administrator to adjust the size of the NFS server duplicate request cache (DRC). The DRC is used by the NFS server to reply to retransmissions of non-repeatable operations (e.g., write, set file attributes). An undersized DRC for a given request load does not allow the NFS server to detect that a non-repeatable operation's RPC has been retransmitted, and hence the server performs the operation again. This can result in data loss or inconsistency. This patch allows the system administrator to adjust the size, as needed, to accomodate the anticipated load on the NFS server. PROBLEM: (96146) (PATCH ID: OSF520-1135) ******** Logins in TruCluster environments using Enhanced Security could hang on any member other than the one serving /var to CFS. This was because the RPC portmapper registration for prpasswdd and rpc.yppasswdd wasn't always being seen by all the members. PROBLEM: (96281) (PATCH ID: OSF520-1169) ******** Changed an incorrect lock in if.c to prevent the cluster from crashing when VMAC is enabled. PROBLEM: (96322) (PATCH ID: OSF520-1187) ******** This patch corrects memory file system size to accommodate the required space while creating bttape advfs/ufs with LSM support. PROBLEM: (96087) (PATCH ID: OSF520-1158) ******** PROBLEM (96087) (PATCH ID: ) The adapter firmware failed to properly update the residue count when a filemark is detected while doing odd byte transfers. This could cause inconsistant data to be returned to the application. PROBLEM: (96196) (PATCH ID: OSF520-1166) ******** This fixes a problem in the Network startup script where we could fail to configure an interface with an IP address. PROBLEM: (96521, 96522) (PATCH ID: OSF520-1246) ******** These two fixes can cause various crashes: 3 _XentMM 4 alloc_hole_stg 5 alloc_stg 6 add_stg 7 stg_add_stg_no_cow 8 stg_add_stg 9 rbf_add_overlapping_stg PROBLEM 4 domain_panic 5 bmt_unlink_mcells 6 alloc_hole_stg 7 alloc_stg 8 add_stg 9 stg_add_stg_no_cow 10 stg_add_stg 11 rbf_add_stg 12 frag_list_extend 13 bs_frag_alloc 14 fs_create_frag 15 bs_close_one PROBLEM 11 domain_panic 12 check_mcell_hdr 13 load_from_xtra_xtnt_rec 14 load_from_xtnt_rec 15 load_inmem_xtnt_map 16 x_load_inmem_xtnt_map 17 frag_list_extend 18 bs_frag_alloc 19 fs_create_frag 20 bs_close_one PROBLEM: (95992, FR_G06761) (PATCH ID: OSF520-1248) ******** This patch fixes two problem where the dynamic runtime loader might cause an application to crash. The first problem incorrectly leaves some libraries loaded in memory after an application calls dlclose(). You might see this problem in the following situations: o The application could crash after subsequent calls to dlopen() and dlclose(). o The application might behave unexpectedly after a call to dlclose() does not unload a library with a specific symbol definition and a subsequent call to dlopen() for another library that contains a symbol definition with the same name. In this case, the loader incorrectly resolves the symbol references to the former symbol and not to the symbol in the newly loaded library. The second problem is a loader crash that occurs when using _RLD_ARGS with an application that closes file descriptor zero. The following is an example of this crash. % cat t.c main() { close(0); } % cc t.c -o a.out The following two commands will then cause the loader to crash. % ( setenv _RLD_ARGS -v ; a.out ) % ( setenv _RLD_ARGS "-v -log ./t.t" ; a.out ) The above two problems only exist in the V5.1, V5.1A, and V5.1B releases and both are fixed with this patch. The first one can only occur when libraries with a particular order of circular dependencies are loaded with dlopen(). PROBLEM: (96532) (PATCH ID: OSF520-1243) ******** There was a small race between setting an internal data structure and dereferencing the pointer in the structure. This submit closes that race which could result in a kernel memory fault on a multiprocessor system. PROBLEM: (96006, 96284, TKT470300) (PATCH ID: OSF520-1171) ******** This patch restores previous exports file behaviors of -root=hostlist. Without this patch, "-rw=hostlist" needs to explicitely defined in the entry in order to get "rw" access. PROBLEM: (96530, 96613) (PATCH ID: OSF520-1249) ******** On a multivolume domain, when one volume runs out of storage, it's possible that ENO_MORE_BLKS could be returned even thought there is more free storage on other volumes. PROBLEM: (96015, FR_G06466, 95686, 86081, GB_G06865) (PATCH ID: OSF520-1173) ******** This patch fixes an underlying problem in the NFS client that could lead to a panic on a single system or an assertion failure panic on a cluster. These conditions would be triggered by the temporary existence of two vnodes for the same mount/file handle combination. PROBLEM: (BCGM508F5, 87393, 87784) (PATCH ID: OSF520-026) ******** This patch corrects the behavior of the sort(1) command which now checks for duplicates with -c -u and -k flags. PROBLEM: (88511, 92964) (PATCH ID: OSF520-734) ******** 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. HP has corrected this potential vulnerability. This fix also addresses the problem wherein Performing a sort on a large database using numerous keys fails during the consolidation phase of the temporary files. PROBLEM: (86874, 95828) (PATCH ID: OSF520-1081) ******** Now sort gives exit value > 1 for all the error messages,in compilance with existing specs.Also sort does not dump core,when more than 50 sort keys are used. PROBLEM: (90390, 94386, 96169, 96295, BCGM400N5) (PATCH ID: OSF520-1237) ******** This patch fixes four problems in the "ee" driver for DE60x Ethernet adapters: 1. Previous versions of the driver would use a full-size buffer for the range of packet lengths from 64-1518 bytes. This patch allows the driver to copy into a small buffer when appropriate to prevent the driver from consuming excessive amounts of memory. 2. A timing window was identified which could result in the occurance of a transmit timeout. The window was closed to prevent the problem. 3. Flow control is now enabled by default in the driver to reduce the possibility of dropping frames. 4. The default size of the receive ring was increased from 32 to 256 entries to enhance receive performance and mitigate the possibility of dropping frames. PROBLEM: (90390, 95778, 95912, 96169, 96407, 96456, 96506, 96570, 96517) (PATCH ID: OSF520-1175) ******** This patch fixes three problems in the "bcm" driver for DEGXA Gigabit Ethernet adapters: 1. Flow control was not enabled in previous versions of the driver for copper adapters. This patch enables flow control to reduce dropped packets while maintaining high performance. Dropped packets, which cannot always be avoided on Ethernet, show up as "frame errors" in the netstat output for "bcm" adapters. 2. Previous versions of the driver would use a full-size buffer for the range of packet lengths from 64-1518 bytes. This patch allows the driver to copy into a small buffer when appropriate to prevent the driver from consuming excessive amounts of memory. 3. This driver modifies the device initialization to avoid a receive problem that can occur in the DEGXA hardware. The problem would be manifested as apparent disconnection from the network, cured only when a "transmit timeout" would eventually reset the adapter. With this patch, the problem is avoided completely. PROBLEM: () (PATCH ID: OSF520-1260) ******** This provides a DDR entry for the DAT-72 tape drive. PROBLEM: (96530) (PATCH ID: OSF520-1255) ******** Prevent kernel memory fault Panic in unusual cases where defragment or rmvol moves a file that has extent mcell(s) with no storage. This problem does not exist in previous releases, it was introduced by a code change to fix out-of space conditions on multi-volume domains.