Direct links to fixes
6.3.6.000-TIV-TSMRPT-AGENT-Linux
6.3.6.000-TIV-TSMRPT-AGENT-AIX
6.3.6.000-TIV-TSMRPT-AIX
6.3.6.000-TIV-TSMRPT-AGENT-Windows
6.3.6.000-TIV-TSMRPT-Linuxx86
6.3.6.000-TIV-TSMRPT-Linuxx86_64
6.3.6.000-TIV-TSMRPT-WindowsI32
6.3.6.000-TIV-TSMRPT-WindowsX64
6.3.6.000-TIV-TSMAC-WindowsX64
6.3.6.000-TIV-TSMAC-WindowsI32
6.3.6.000-TIV-TSMAC-SolarisSPARC
6.3.6.000-TIV-TSMAC-Linuxx86
6.3.6.000-TIV-TSMAC-Linuxs390x
6.3.6.000-TIV-TSMAC-AIX
6.3.6.000-TIV-TSMALL-SolarisSPARC
6.3.6.000-TIV-TSMALL-WindowsX64
6.3.6.000-TIV-TSMSTA-WindowsI32
6.3.6.000-TIV-TSMALL-HP-UX
6.3.6.000-TIV-TSMALL-Linuxppc64
6.3.6.000-TIV-TSMALL-AIX
6.3.6.000-TIV-TSMALL-Linuxs390x
6.3.6.000-TIV-TSMALL-Linuxx86_64
7.1.3.000-TIV-TSMSRV-WIN
7.1.3.000-TIV-TSMSRV-SolarisSPARC
7.1.3.000-TIV-TSMSRV-Linuxx86_64
7.1.3.000-TIV-TSMSRV-Linuxs390x
7.1.3.000-TIV-TSMSRV-Linuxppc64
7.1.3.000-TIV-TSMSRV-HP-UX
7.1.3.000-TIV-TSMSRV-AIX
IBM Tivoli Storage Manager V6.3 Fix Pack 6 (6.3.6.000) Server Downloads
APAR status
Closed as program error.
Error description
If two scheduler command execution threads, executing the IDENTIFY DUPLICATES command, run at the same time, a mutex acquisition deadlock can occur which causes other server threads to hang. Diagnosing the problem: While the problem is occurring, collect the output of the Storage Manager server command 'SHOW THREADS' and look for two CsRunCmdThread threads, one of which is acquiring mutex 'BFV->mutex' and the other acquiring mutex 'threadInfoP->mutex': Thread 23471, Parent 89: CsRunCmdThread, Storage 130645, AllocCnt 113 HighWaterAmt 175310 tid=140143760840448, ptid=140145400809216, det=1, zomb=0, join=0, result=0, sess=0 Holding mutex threadInfoP->mutex (0x0x3c9d528), acquired at bfdedup.c(1462) Acquiring mutex BFV->mutex (0x0x3c1d6a8) at bfdedup.c(1524) lwp=40049 Thread 23472, Parent 89: CsRunCmdThread, Storage 108848, AllocCnt 80 HighWaterAmt 128715 tid=140143775180544, ptid=140145400809216, det=1, zomb=0, join=0, result=0, sess=0 Holding mutex BFV->mutex (0x0x3c1d6a8), acquired at bfdedup.c(1854) Acquiring mutex threadInfoP->mutex (0x0x3c9d528) at bfdedup.c(1462) lwp=40050 This conflict will cause other threads attempting to aquire a BFV mutex to hang. The call stack of the hung threads will show the following calls (from a Linux server): __lll_lock_wait () from /lib64/libpthread.so.0 _L_lock_854 () from /lib64/libpthread.so.0 pthread_mutex_lock () from /lib64/libpthread.so.0 pkAcquireMutexTracked ()
Local fix
If there are two identify duplicate schedules starting at or about the same, the problem might be avoided by scheduling one of them at a later time.
Problem summary
**************************************************************** * USERS AFFECTED: * * All Tivoli Storage Manager server users. * **************************************************************** * PROBLEM DESCRIPTION: * * See error description. * **************************************************************** * RECOMMENDATION: * * Apply fixing level when available. This * * problem is currently projected to be fixed * * in levels 6.3.6 and 7.1.3. Note that this is * * subject to change at the discretion of IBM. * ****************************************************************
Problem conclusion
This problem was fixed. Affected platforms: AIX, HP-UX, Solaris, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT09425
Reported component name
TSM SERVER
Reported component ID
5698ISMSV
Reported release
71L
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-06-11
Closed date
2015-07-01
Last modified date
2015-07-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
TSM SERVER
Fixed component ID
5698ISMSV
Applicable component levels
R63S PSY
UP
R63H PSY
UP
R63L PSY
UP
R63S PSY
UP
R63W PSY
UP
R71A PSY
UP
R71H PSY
UP
R71L PSY
UP
R71S PSY
UP
R71W PSY
UP
Document Information
Modified date:
01 July 2015