Error Message

Analysis of resulting forced crash dumps will show the commands and stack hung, like below:
[0 10:35:41.242] [UN] PID: 41514 TASK: ffff9ae0e8ed9ec0 CPU: 18 COMMAND: "python27_ime"
[0 10:35:41.252] [UN] PID: 41501 TASK: ffff9ad75dfc5c40 CPU: 18 COMMAND: "python27_ime"
[0 10:35:41.280] [UN] PID: 41393 TASK: ffff9ad04f448000 CPU: 20 COMMAND: "python27_ime"
[0 10:35:42.335] [UN] PID: 37996 TASK: ffff9acfcba19ec0 CPU: 28 COMMAND: "python27_ime"
[0 10:35:43.294] [UN] PID: 34472 TASK: ffff9acf34dd5c40 CPU: 17 COMMAND: "python27_ime"
[0 10:35:43.341] [UN] PID: 34266 TASK: ffff9adeb566bd80 CPU: 22 COMMAND: "python27_ime"
[0 10:35:43.505] [UN] PID: 33597 TASK: ffff9adc99c15c40 CPU: 1 COMMAND: "python27_ime"
[0 10:35:43.668] [UN] PID: 32825 TASK: ffff9acfa35f3d80 CPU: 8 COMMAND: "dcs_operation_m"
[0 10:35:43.681] [UN] PID: 32811 TASK: ffff9ad0baa4bd80 CPU: 14 COMMAND: "dcs_operation_m"
[0 10:35:44.270] [UN] PID: 30996 TASK: ffff9ad1001f8000 CPU: 6 COMMAND: "dcs_operation_m"
[0 10:35:50.470] [UN] PID: 20146 TASK: ffff9addf6be0000 CPU: 14 COMMAND: "dcs_operation_m"
[0 10:35:55.998] [UN] PID: 6767 TASK: ffff9ae0be299ec0 CPU: 17 COMMAND: "dcs_operation_m"
[0 10:36:00.119] [UN] PID: 55697 TASK: ffff9ad74f679ec0 CPU: 23 COMMAND: "dcs_operation_m"
[0 10:36:07.597] [UN] PID: 30429 TASK: ffff9ad6008dbd80 CPU: 24 COMMAND: "pra_assembly_ta"
[0 10:36:09.435] [UN] PID: 25270 TASK: ffff9ac3ec47dc40 CPU: 22 COMMAND: "python27_ime"
[0 10:52:54.516] [UN] PID: 13629 TASK: ffff9adfb5ef3d80 CPU: 10 COMMAND: "vx_oipool_thr"

crash> bt 41514
PID: 41514 TASK: ffff9ae0e8ed9ec0 CPU: 18 COMMAND: "python27_ime"
#0 [ffffac1af9227bb0] __schedule at ffffffffa3d4a1b4
#1 [ffffac1af9227c48] schedule at ffffffffa3d4a628
#2 [ffffac1af9227c58] rwsem_down_write_slowpath at ffffffffa353bfca
#3 [ffffac1af9227d00] path_openat at ffffffffa3728ec7
#4 [ffffac1af9227dd8] do_filp_open at ffffffffa372b423
#5 [ffffac1af9227ee0] do_sys_open at ffffffffa3716094
#6 [ffffac1af9227f38] do_syscall_64 at ffffffffa340420b
#7 [ffffac1af9227f50] entry_SYSCALL_64_after_hwframe at ffffffffa3e000ad
RIP: 00007f1c5300e04f RSP: 00007ffee3f01a00 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 00007ffee3f01c70 RCX: 00007f1c5300e04f
RDX: 0000000000000042 RSI: 00007ffee3f01c70 RDI: 00000000ffffff9c
RBP: 00000000012152f0 R8: 00007ffee3f022f0 R9: 00007f1c4f0dd580
R10: 00000000000001b4 R11: 0000000000000246 R12: 0000000000000402
R13: 0000000000d66a48 R14: 00007f1c4be0cd60 R15: 000000000000000f
ORIG_RAX: 0000000000000101 CS: 0033 SS: 002b

The cluster hang is observed due to a deadlock within VxFS within one of the structures used.

There are no plans to address this issue by way of a patch or hotfix in earlier versions of the software at the present time.  However, the issue has been addressed in the revision of the product specified at the end of this article. 
 
Please contact your Veritas Sales representative or the Veritas Sales group for upgrade information including upgrade eligibility to the release containing the resolution for this issue.

VxFS 7.4.2.2201 addresses the issue. Please refer to Veritas Technical Support for the fix.

The Issue is also addressed in 7.4.2 Update 4, which is available here