I faced with that error on 11.2.0.1 two node RAC on AIX system with ASM. One of our instance reboot itself and database alert.log mention below errors:

 ORA-00600: internal error code, arguments: [kjbrref:pkey], [2630360], [481], [1113572], [0], [], [], [], [], [], [], []
 Incident details in: lms3_3211996_i4178879.trc
 Fri Feb 17 21:10:14 2019
 Trace dumping is performing id=[cdmp_20120217211014]
 Fri Feb 17 21:10:17 2019
 Sweep [inc][4178879]: completed
 Sweep [inc2][4178879]: completed

We raised Sr and got that  explanation from Oracle:

It is a known issue,From 11.2, for DRM , we have an additional concept called gc read mostly concept in which if this gc read mostly lock is acquired by an instance which reads a block 50 times more than the other instance/(s)

The lock is acquired on the object’s block and if another instance calls the same block for 50 more times than the current instance which is acquiring the lock, the lock gets moved to the new instance This is called block affinity gc read mostly feature in 11.2 .Obviously, due to this lock, overheads and latencies are expected behavior and LMS getting stuck in DRM is a known issue when using this Disabling the gc read mostly locking will help you avoid many known issues like ORA-600 errors leading to instance crashes:-
Refer:-
Bug 12408350 – ORA-600 [kjbrasr:pkey] in RAC with read mostly locking (Doc ID 12408350.8)
So, in other words, please set the hidden parameter “_gc_read_mostly_locking”=FALSE scope=spfile for all the instances of the database and bounce the database instances for this parameter to take effect

Some additional metalink notes:
ORA-600 [kjbrasr:pkey] [ID 406803.1]
Instance Crashes with ORA-00600 [kjbrref:pkey] [ID 1106052.1]
Top 5 RAC Instance Crash Issues [ID 1375405.1]  << Issue 3