PROBLEM: (QAR 51876) (Patch ID: TCR100-007) ******** 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 "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 "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: (MCPM40SMV and QAR 53502) (Patch ID: TCR100-010) ******** 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: TCR100-010) ******** 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: (SHGBS5101 & QAR 59405) (Patch ID: TCR100-022) ******** 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()