Feb 17 00:53:01  device-re0 fpc1 fpc1 dcpfe: pechip_cmerror_fo_intr_handler:26244: PE0[0]: FO core intr: Fab Packet length error

Feb 17 00:53:01  device-re0 fpc1 fpc1 dcpfe: pechip_cmerror_fo_intr_handler:26250: PE0[0]: FO core intr: LS Packet length error

Feb 17 00:53:02  device-re0 fpc1 HMC DRAM SBE PE0[0]: HMCIF: Link1:cmd:56 lng:9 ltag:132 dinv:1 errstat:31 err_cnt:0xc0 total sbe error:0x400 

Feb 17 00:53:02  device-re0 fpc1 pechip_cmerror_fo_intr_handler:26244: PE0[0]: FO core intr: Fab Packet length error

Feb 17 00:53:02  device-re0 fpc1 fpc1 dcpfe: HMC DRAM SBE PE0[0]: HMCIF: Link1:cmd:56 lng:9 ltag:132 dinv:1 errstat:31 err_cnt:0xc0 total sbe error:0x400#012

Feb 17 00:53:02  device-re0 fpc1 fpc1 dcpfe: pechip_cmerror_fo_intr_handler:26244: PE0[0]: FO core intr: Fab Packet length error

Feb 17 00:53:03  device-re0 fpc1 pechip_cmerror_fo_intr_handler:26244: PE0[0]: FO core intr: Fab Packet length error

1. Loss of requests leading to packet drops in the fabric.
2. Alarm is raised.

In ASIC if a page (not packet) is sitting in the active VOQ for a long time it gets timed out and ASIC raise FO interrupts
 

pechip_cmerror_fo_intr_handler:26256: pe2[2]: FO core intr: Fab Page time out error
pechip_cmerror_fo_intr_handler:26244: pe2[2]: FO core intr: Fab Packet length error

   
Normally we see this in two scenarios :
 
  1. When strict-priority-scheduler is configured where Low Priority queue completely get starved by Higher priority queue for long time
  2. or with host bound interface when very high traffic on host path, however that will count LS (local switch) Fab Page Timeout
 

This makes these logs transient in nature.

Actions to take:

1. This is an auto-recoverable error
2. FPC restart/reconfig may be needed only if this interrupt gets triggered too often.
3. Contact TAC Representative if this issue is seen frequently.