Update of 25 April 2005
The Tru64 UNIX 5.1B-1/PK3
Early Release Patch (ERP) kit announced in this Engineering
Advisory (EA) has been replaced by a new 5.1B-1/PK3 ERP kit. The
new ERP, T64KIT0025392-V51BB24-E-20050418.tar, combines the
memory leak fix described in this EA with two additional fixes
that also affect advfs.mod. The new fixes avoid two panics
resulting from quotactl requests on AdvFS filesets:
- kernel memory fault in dyn_hash_remove
- panic "lock_terminate: lock held"
See EA BU050414_EW01 (Panics During quotactl Calls) for details
on the new fixes.
The 5.1B PK2 kit announced in this EA remains unchanged.
The original problem description follows.
A memory leak exists in a routine that vfast uses to merge extent
maps. The routine is not freeing allocated memory in bucket 1
(32-byte bucket). The problem manifests as an inordinate amount
of memory being used in bucket 1. It can be identified by
issuing the vmstat -M command and viewing the bytes_in_use
column for bucket 1.
This problem only occurs when using vfast. The
workaround is to issue "vfast deactivate dmnName" for all
domains with vfast activated.
ERP Kit Notes
The memory leak is present in HP Tru64 UNIX V5.1B PK2 and V5.1B
PK3. HP has resolved the problem by providing the two ERP kits
listed in the Resolution section.
Both kits contain a revised advfs.mod.
The V5.1B PK3 ERP Kit
The 5.1B-1/PK3 kit now contains three fixes:
- The memory leak fix described in this EA
- kernel memory fault in dyn_hash_remove (new)
- panic "lock_terminate: lock held" (new)
The V5.1B PK2 ERP Kit
The V5.1B PK2 kit combines the memory leak fix with two
previous V5.1B PK2 fixes that also affect advfs.mod. The earlier
fixes were released as V5.1B PK2 ERP kits and are being combined
with the memory leak fix for customer convenience. Both previous
fixes are available in V5.1B PK3 (BL24).
Specifically, the HP Tru64 UNIX V5.1B PK2 ERP kit contains
fixes that address the following three issues:
- Memory leak in bucket 32 when using vfast, which is
described in this EA
- AdvFS panic in _OtsMove
A system can panic with a kernel memory fault in _OtsMove if
threads are performing AdvFS direct I/O read operations. The
panicing thread in the crash has the following stack trace
- Possible Memory Corruption:
Under certain circumstances, memory corruption can occur when
a non-Tru64 UNIX NFS client attempts to increase the size of an
AdvFS file. The problem usually appears as a kernel memory fault
and corruption in multiple kernel memory buckets. A thread in
the crash has the following stack trace segment: