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.
DESCRIPTION
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 segment:
[...]
6 _XentMM
7 _OtsMove
8 uiomove
9 uiomove_frag
10 fs_read
[...]
- 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:
[...]
5 _OtsZero
6 fs_setattr
[...]
|
