PROBLEM: (QAR 51876) (Patch ID: TCR141-014) ******** This patch corrects an assertion panic that occurs after a large number of transactions are made using the same lock. The assertion panic is triggered by integer wrapping of the lock transaction ID field. The system may panic with "dlm_panic". The actual assertion message is "lk_txid == 0>". The symptom of the problem is an assertion panic which will print on the console as "dlm_panic". If one examines the newest crash data file in the /var/adm/crash directory you will see the actual assertion message "lk_txid == 0>". This problem can occur only after a large number of transactions are made using the same lock. In one case it took ~13 days for this to happen. PROBLEM: (QAR 51988) (Patch ID: TCR141-014) ******** This patch corrects an erroneous assertion involving deadlock search. The system may panic with "dlm_panic". The actual assertion message is "". The symptom of the problem is an assertion panic which will print on the console as "dlm_panic". If one examines the newest crash data file in the /var/adm/crash directory you will see the actual assertion message "". It is very unlikely this will happen in the field because it requires the mixing of certain DLM features which applications would not normally combine. This particular problem was only found during internal testing. PROBLEM: (MCPM40SMV and QAR 53502) (Patch ID: TCR141-022) ******** This patch fixes a problem resulting from DLM not checking the effective group ID when a process tries to join a namespace. As a result, only processes holding the real group ID corresponding to the namespace ID could join a namespace, even if the DLM_GROUP flag was used in the dlm_nsjoin() call. PROBLEM: (TKTB43444 and QAR 52745) (Patch ID: TCR141-022) ******** This patch fixes a problem in dlm_quecvt() where a failed attempt to convert a lock with DLM_NOQUEUE set, would not clear the DLM_BUSY state for the lock. This caused all subsequent calls to dlm_quecvt() for the lock to return a status of DLM_LKBUSY even though the lock was not busy. PROBLEM: (DEKQ70230, QAR 54589) (Patch ID: TCR141-026) ******** This patch fixes a problem in the TruCluster Production Server Software in which a system can panic with: rcv_invvalb_req: value block out of sequence This panic occurs when a rebuild of the distributed lock manager (DLM) database starts and a process that was holding remote locks is exiting. A typical stack trace would look like: 0 stop_secondary_cpu() 1 panic("event_timeout: panic request") 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic("rcv_invvalb_req: value block out of sequence") 6 rcv_invvalb_req() 7 dlm_process_message() 8 dlm_recv() PROBLEM: (SHGBS5101 & QAR 59405) (Patch ID: TCR141-040) ******** This patch fixes a problem that can cause a cluster member to panic in rcv_deqlk_msg() with the panic string set to: dlm_panic A typical stack trace would look like: 0 stop_secondary_cpu() 1 panic("event_timeout: panic request") 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic("dlm_panic") 6 dlm_panic() 7 rcv_deqlk_msg() 8 dlm_process_message() 9 dlm_recv() PROBLEM: (MGO103549) (Patch ID: TCR141-046) ******** This patch fixes a system panic with the following message, "snd_grantlk_msg: no memory for message". PROBLEM: (HGOAB4786) (Patch ID: TCR141-054) ******** This patch fixes a dlm_panic if a process is exiting and a rebuild for the Distributed Lock Manager (DLM) takes place. A possible stack trace would look like: 0 stop_secondary_cpu() 1 panic("event_timeout: panic request") 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic("dlm_panic") 6 dlm_panic() 7 snd_invvalb_req() 8 dlm_proc_exit() 9 xa_handler_callout() 10 exit() 11 sigexit() 12 psig() 13 syscall() 14 _Xsyscall() PROBLEM: (MCGMA1HNX & HPAQ41D80) (Patch ID: TCR141-055) ******** This patch fixes a problem that caused the command: 'sysconfig -q dlm' to hang if DLM is currently suspended. PROBLEM: (MGO103933) (Patch ID: TCR141-059) ******** This patch fixes a problem when a system in a TruCluster panics with the following data: panic string: "dlm_panic" A typical stack trace would look like the following: 5 panic 6 dlm_panic 7 deq_granted 8 deq_one_lock 9 deq_lock 10 dlm_unlk 11 syscall 12 _Xsyscall