vxconfigd behaves erratically if there is more than 40GB of physical memory on an AIX system
|Article:TECH146916|||||Created: 2010-12-23|||||Updated: 2010-12-31|||||Article URL http://www.symantec.com/docs/TECH146916|
vxconfigd behaves erratically if there is more than 40GB of physical memory on an AIX system. The following are some of the reported erratic behavior.
1. Running "vxdctl enable" causes vxconfigd to lose the licenses
2. Veritas Volume Manager (VxVM) commands fails because of "Memory allocation failure" error
3. vxconfigd dies on the Veritas Volume Replicator (VVR) secondary during synchronization started by "vradmin syncrvg" command
Please note that there can other unpredictable errors reported by vxconfigd.
The following are some of the reported errors when the problem is hit:
1. Loss of License
# vxdctl enable
VxVM vxconfigd ERROR V-5-1-1589 enable failed: License has expired or is not available for operation
transactions are disabled.
VxVM vxdctl ERROR V-5-1-1589 enable failed: License has expired or is not available for operation
2. VX commands fail
vxconfigd can cause VX commands to fail with "Memory allocation failure".
For example, a "vxdg init" command can fail with the following error.
VxVM vxdg ERROR V-5-1-585 Disk group dg_74: cannot create: Memory allocation failure
3. vxconfigd core dumped
vxconfigd can coredump on a VVR secondary while resynchronization (vradmin syncrvg) is running.
#dbx /sbin/vxconfigd.5.3 /core
IOT/Abort trap in pth_signal.pthread_kill [/usr/lib/libpthread.a] at
0xd0124734 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
pth_signal.pthread_kill(??, ??) at 0xd0124734
pth_signal._p_raise(??) at 0xd01241a4
raise.raise(??) at 0xd0388cd0
abort() at 0xd03ecb78
__assert_c99(??, ??, ??, ??) at 0xd03f7b8c
ddlproperty.ddl_get_asso_ts() at 0x10076ce4
ddlproperty.ddl_get_dynamic_attr() at 0x10077ddc
ddlproperty.ddl_check_for_dynamic() at 0x10077fc4
ddlproperty.get_asso_ts() at 0x10078b78
req_ddl_get_assoc() at 0x1004a86c
request_loop() at 0x1000c798
main() at 0x10001498
This problem is specific to the AIX platform only.
This issue only applies to configuration where all of the following apply:
1. Veritas Volume Manager 5.0MP3RP3 or below, VxVM 5.1 RP1 or below
2. AIX system with more than 40GB of physical memory
The problem was caused by the Etrack incident listed in the Supplemental Material section of this article. There was an explicit ulimit() call inside vxconfigd to set the DATALIM (Data Segment Limit). The Data Segment Limit was set to 10% of the total physical memory by the explicit ulimit() call. Due to the Etrack incident a 32-bit value is used. If the system has a physical memory of more than 40960MB (about 40GB), the 10% of this value will overflow the 32-bit variable and as a result incorrect parameter is passed to ulimit(). Depends on the actual physical memory size, this can cause vxconfigd to limit its own Data Segment Size to a very low value. If the Data Segment Size is too low, vxconfigd will behave erratically.
The problem is fixed in the following patches on the AIX platform.
VxVM 5.1SP1 and onwards
VxVM 5.1RP2 and onwards
VxVM 5.0MP3 RP4 and onwards
Symantec always recommends customers to apply the latest official patches if possible. Please download the latest patches from the Symantec Operation Readiness Tools (SORT) website.
If applying the above official patches is not possible, a hotfix is available on the 5.0MPRP3 patch level.
VxVM 5.0MP3RP3 HF3
Pleaes contact Symantec technical support if the hotfix is required.
vxconfigd memory allocation failure occurs in large configurations
Article URL http://www.symantec.com/docs/TECH146916