Using Database Flash Cache does not mean you will hit this problem with your usage.
There are potentially two or more bugs which have similar symptoms but unique fixes, but all share the pre-requisites of:

• Flash Enabled or storage on shared FLASH disks
• Two or more nodes ¹
  
  

This can occur on any platform that uses Flash Cache on more than the local node,
When using the DB Smart Flash Cache feature in ODA X5-2 the remote FLASH CACHE is automatically accessible to the opposing node
Otherwise, this problem typically requires a RAC configuration with database Flash cache enabled and accessible for two or more nodes.

(Doc ID 2120400.1). Formerly Labeled     -- ODA X5-2: Lock, Hang for Checkpoint (CKPT) or DBwriter (DBWR), 'GC CURRENT REQUEST' or Intermittent Bad Performance, High CPU and / or Very Poor IO 

* The Oracle Database Appliance (ODA) X5-2 by default automatically enables remote access to the FLASH DISK GROUP* on both nodes if cache size <> 0:
    regardless of the instance type: even if using Enterprise Edition (EE) which is a single-instance database.

   Please upgrade to the newest version of the ODA if using FLASH on X5-2: There are also several single-patches and merges available or in the process of being created.

 
Note:     Oracle Database Appliance X5-2 introduces four additional 400 GB SSDs in slot numbers 16-19 that can be used to host database files, or they can be used as a database flash cache in addition to the buffer cache.

An ASM diskgroup named +FLASH with Normal Redundancy is provisioned on these SSDs. All of the storage in the +FLASH diskgroup is allocated to an ASM Dynamic Volume (flashdata), and formatted as an ACFS file system.
Storage in this flashdata file system is then made available as an ACFS file system and is used to create database flash cache files that accelerate read operations.

     The file that contains the flash cache is automatically created for each database and is specified using the database init.ora parameter db_flash_cache_file.
By default, flash_cache_file_size is set to 3 times the size of SGA, up to 196 GB, unless there is not enough space, in which case the size parameter is set to 0.
Changing the flash_cache_file_size parameter requires restarting the database in order to use the newly sized flash cache.

Then, as appropriate: Apply merge or single-patch bug fixes for the following known issues:
- Fixed on or by 12.1.2.9.0 currently released 12/7/2016

 20048359 - PARALLEL QUERY CONSUMES CPU TIME ON RAC WITH DATABASE SMART FLASH CACHE
 22083366 - LNX64-112-CMT: CKPT BLOCKING SESSION DURING INDEX REBUILD USING FLASH CACHE

• high 'ENQ: RO - FAST OBJECT REUSE' ;
• blocking session is the process CKPT ; 
• DBWR is the top process on one instance 
  
  "...We have seen two issues. One is DBWR not picking up the write permission granted to start the write for a while.  This issue is looking at by buffer cache.
    From DBW trace, PI buffers not getting written
   N/A -"...There is another issue from long latency with IPC. This is running RDS/IP on exadata. We have seen long delay occasionally for IPC messages from 4 seconds or more between two nodes.his is not DLM issue, but possible RDS driver or environment issue [Exadata] ..."
  
  Per checking v$session/v$session_blockers, we found this event occurs while truncate tables on instance 1, the
  blocking session is the process CKPT on instance 2, and the  process DBWR on instance 2 is the top one.
  
  Diagnostic:
  Do CKPT and DBWR trace using the parameter _obj_ckpt_tracing = 1 and _dbwr_tracing=26.
  The result is  *1_* is the trace of instance 1 and *2_* is trace of another node.

• gc buffer busy acquire waiting on two sessions between two nodes
• Hit cache fusion lock hang when flash cache is enabled.
• Session hang as the request was dropped at master due to rapidly wrapped lock sequence.
• not consistently reproducible, In previous tests, it took up to 10 hours with the workload running continuously for the sessions to hang.

PID   USER PR NI VIRT RES SHR S   %CPU  %MEM  TIME+ COMMAND

4981 oracle 20 0  18.4g 33m 21m R  100.0   0.0  172:09.84 ora_dbw1_tst1
4998 oracle 20 0  18.4g 34m 23m R  100.0   0.0  172:08.60 ora_dbw4_tst1
4976 oracle 20 0  18.4g 36m 24m R    99.8   0.0  172:15.84 ora_dbw0_tst1
4985 oracle 20 0  18.4g 33m 21m R    99.8   0.0  172:11.11 ora_dbw2_tst1
...
...
Short stacks from DBW processes:

ksedsts()+647<-ksdxfstk()+58<-ksdxcb()+901<-sspuser()+227<-__sighandler()<-kcbo_service_ockpt()+1265<-kcbbdrv()+8841<-ksbabs()+539<-ksbrdp()+1209
<-opirip()+1475<-opidrv()+610<-sou2o()+145<-opimai_real()+270<-ssthrdmain()+412<-main()+236<-__libc_start_main()+244

10046 trace files show DBWR processes making very little progress:

*** 2014-09-02 12:08:16.369
WAIT #0: nam='db file parallel write' ela= 6125 requests=1 interrupt=0
timeout=2147483647 obj#=-1 tim=3158416120020
WAIT #0: nam='db file async I/O submit' ela= 2 requests=1 interrupt=0
timeout=0 obj#=-1 tim=3158416151066
WAIT #0: nam='db file parallel write' ela= 4849 requests=1 interrupt=0
timeout=2147483647 obj#=-1 tim=3158416155959

    "...Tried the same test with different configurations:( and the problem does not reproduce )
     - Single instance, cluster_database=FALSE
     - RAC 2 nodes, workload on node 1, node 2 idle
...
      In both cases, the drop statement completed in less than 30 seconds vs. 26+ hours.
      DBWR processes were at 100% CPU utilization during that time..."

Requires
Cluster configuration
Flash enabled

free buffer inspected' increases dramatically -- This represents number of examined buffer to reuse but failed to reuse.

CPU time is occupied for 85% of the overall execution time.
CPU time is used by parallel slave processes.

QC. 12 parallel slave processes are running.
These processes got/released the latch "cache buffers lru chain" and "cache buffers chains".

"...DBWR cannot keep up with foregground requests to move SCURRENT buffer to flash cache..."

Requires
Cluster Configuration
Flash enabled

DIAGNOSTIC ANALYSIS:
--------------------
The waits for 'enq: TM - contention' were caused by long 'gc current request' waits.
waiting for 'gc current request'

• DBWR might spin with flash cache in RAC
• dbw0 spins if it can not shrink an LE to Flash lock.

• Continuously consuming close to 100% DBW background processes.

34745 oracle 20 0 2415m 33m 23m R   99.8  0.0 8179:44 ora_dbw0_...  <<<<<<<<<<<
34749 oracle 20 0 2413m 31m 21m R   98.8  0.0 8181:48 ora_dbw1_... <<<<<<<<<<<

• dbwrs busy with writes
• dbwr high cpu (top)

• LMON might crash the instance during normal shutdown.
• Instance crashed.
• lmd0 hit ora-600[kjmscndscq:timeout]
• 'latch: gc element'
• 'latch: cache buffers chains'
• LMS (ospid: ###) has not moved for ## sec

==============================
     LMS2 (ospid: 8096) has not moved for 90 sec (1441188604.1441188514)
     : heartbeat check status 6 (no-heartbeat) (threshold 70 sec)

DBW1 attempted to close a fusion lock with latch held.

Process DBW1 (ospid: ####): latch state and session wait history

Waiting For:
   0x6802ede10 Child 'gc element' (level=3, SGA latch, child#=19)
    Holder Location: kcl2.h LINE:4755 ID:kcl_le2flash:
Holder Context: 0
Waiter Location: kcl2.h LINE:4602 ID:kclantilock_1:
Latch State:
state=busy (exclusive) [value=0x100000000000002e]


STACK TRACE:
------------
Short stack dump:

ksedsts()+409<-ksdxfstk()+71<-ksdxcb()+912<-sspuser()+215<-__sighandler()<-semop()+7<-skgpwwait()+200<-kslgess()+2789<-
ksl_get_shared_latch_int()+3318<-kclantilock()+501<-kjblprmexp()+994<-kjbmprmexp()+1668<-kjmxmpm()+936<-kjmpbmsg()+6259<-
kjmsm()+26026<-ksbrdp()+1065<-opirip()+545<-opidrv()+594<-sou2o()+145<-opimai_real()+205<-ssthrdmain()+412<-main()+262<-__libc_start_main()+253

Also

Current Wait Stack:
1: waiting for 'gcs drm freeze in enter server mode'
...
ksedsts()+409<-ksdxfstk()+71<-ksdxcb()+912<-sspuser()+215<-__sighandler()<-semtimedop()+10<-skgpwwait()+200<-ksliwat()+2192<-kslwaitctx()+196<-
kjsdrmwt()+1172<-kjsmbesmi()+10365<-kjbclose()+3304<-kcl_le2flash()+2371<-kcbbic_l2()+4361<-kcbbiop_l2()+1157<-kcbbdrv()+8619<-ksbabs()+665<-
ksbrdp()+1065<-opirip()+545<-opidrv()+594<-sou2o()+145<-opimai_real()+205<-ssthrdmain()+412<-main()+262<-__libc_start_main()+253
...

Requires
Cluster configuration
Flash enabled

• CKPT is blocking other sessions
• "library cache load lock"
• "write complete waits"
• "latch: cache buffers lru chain"
• Checkpoint hang which is blocked by flash buffers.
• Customer can't reproduce the hang if he disabled the flash cache.
  It seems to be independent of the size of the redo logs.

• Truncate statement hanging on "gc current request"
• Waiting for 'gc current request'
• We had to restart the complete database every two days
• Can't reproduce the hang after disabling the flash cache.

ksedsts()+244<-ksdxfstk()+58<-ksdxcb()+918<-sspuser()+224<-__sighandler()<-__poll()+47<-ssskgxp_poll()+63<-sskgxp_selectex()+423<-skgxpiwait()+3894<-skgxpwaiti()+1900<-skgxpwait()+178<-
ksxpwait()+2585<-ksliwat()+9356<-kslwaitctx()+161<-ksxprcv_int()+6182<-ksxprcvimdwctx()+59<-ipc_wait_ctx()+359<-kcllkopb()+2133<-kclgrlk()+1574<-kcbzib()+31106<-kcbgcur()+22133<-
ktbgcur()+130<-kdifrb()+645<-kkbtis_trunc_idx_seg()+1333<-kkbindl()+745<-kkbtrndotbl()+571<-kkbtrndo1()+321<-kkbtrn()+2389<-opiexe()+23473<-opiosq0()+4559<

• waiting for 'gc current request'
• A process hung waiting for 'gc current request'.
  Resource dump on the master instance showed it was blocked by a flash shadow.
• Truncate Table
• wait times: snap=1263 min 54 sec, exc=1263 min 54 sec, total=1263 min 54 sec <<<<<<<<<<
  wait times: max=infinite
• request was blocked by a flash shadow on the master instance (instance 2)
• GCS RESOURCE END
  -> GCS SHADOW END

ODA BASED - Here are more ODA X5-2 filed bugs which expand on the above similar bugs

Bug:20248397 - ODA - FLASH CACHE REMOTE SERVICE MISBEHAVE ON RAC DATABASE
Bug:20780960 - FOR ODA ONLY: WHEN ONE INSTANCE CRASHES ITS FLASH CACHE IS LOST
Bug:21171684 - FOR ODA ONLY: RESERVE MEMORY FOR A DEAD INSTANCE'S FLASH CACHE
Bug:21175460 - FOR ODA ONLY: RECOVER A DEAD INSTANCE'S FLASH CACHE 

OVERVIEW

 When using the DB Smart Flash Cache feature in ODA, parameter '_cluster_flash_cache_slave_file' is automatically set to point  to the remote instance's DB flash cache.
- Slightly understated: You do NOT need a second instance such as RAC to see tis problem: ODA USES BOTH NODES FLASH REGARDLESS OF DATABASE TYPE

@ INTERNAL PROBLEM DESCRIPTION:

@ When using the DB Smart Flash Cache feature in ODA, instead of
@ manually setting parameter '_cluster_flash_cache_slave_file' on
@ each instance, it will now be automatically set to point to the
@ remote instance's DB flash cache.
@
@ This reduces the number of parameters the customer needs to set.

@ INTERNAL FIX DESCRIPTION:

@ In short, when 'ODA' is used, after both instances are up, a new
@ message ('KJX_CFC_SND') is sent to the remote instance. This message
@ contains the list of 'db_flash_cache_file' filenames. When the
@ remote instance receives this message, it calls function 'kspsetv0()'
@ to set parameter '_cluster_flash_cache_slave_file' with these values.