Description

This article explains the meaning of the message, 'D4P-x/x: FROML tx192 data path stuck' .

Symptoms

This message is seen after OC192 interfaces go down. 

Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 514, ifAdminStatus up(1), ifOperStatus down(2), ifName as7
Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 588, ifAdminStatus up(1), ifOperStatus down(2), ifName so-6/3/0
Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 120, ifAdminStatus up(1), ifOperStatus down(2), ifName as7.0
Jun 19 23:12:46  router fpc6 D4P-6/3: FROML tx192 data path stuck
Jun 19 23:12:47  router fpc6 D4P-6/3: FROML tx192 data path stuck
Jun 19 23:12:47  router fpc6 LCHIP(3): 1 new errors in LSIF
Jun 19 23:12:48  router fpc6 D4P-6/3: FROML tx192 data path stuck

On OC48 interfaces, a similar message ' D4P-x/x: FROML tx48 data path stuck ' is logged.

Solution

This log can be seen if garbage data is tranferred to sonet framer D4P chip on PIC in some transient state. During transient state or initialization, some garbage data flowed into D4P froml (egress) FIFO.

Garbage data is small in size, and EOP info is not set. This garbage data consumes some D4P buffer. D4P does not drain this data until more data comes into the buffer, but this OC48/192 port is unused and no more data will come into D4P. Eventually, garbage data resides in D4P for a long time. Periodic health check reports this status as data-path stuck.

This log will not be seen in OC48/192 ports which are in use. D4P of used sonet interface will have successive packet, and those successive data triggers D4P to drain data from it's buffer. Then the garbage data will be flushed out.

If the log stops after interfaces come online, it can safely be ignored.
 
D4P buffer will be purged if data-path stuck is reported five times because data-path stuck can be reported five times at most.
This is considered as normal status of the initialization period.