2403381_en-US

[#1]

T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

I'm debugging an Ethernet issue on a T1040 using the 1G mEMAC RGMII interfaces. I am seeing packet loss on an Ethernet port when a different port loses physical link (e.g. the cable is disconnected). This appears to happen most frequently when both ports are operating at high data rates.

When the issue occurs, I see the `TX_FIFO_OVFL` bit set in the Interrupt Event Register (`IEVENT`) of the healthy port.

My current interpretation is that when an actively transmitting mEMAC loses physical link, something in the FMan/mEMAC transmit path temporarily prevents another mEMAC from draining its TX FIFO quickly enough. The healthy port eventually reports `IEVENT[TX_FIFO_OVFL]` and frames are lost. However, I have not identified the shared resource or mechanism that could cause this behavior.

My questions are:

* Is this a known T1040 / FMan v3 / mEMAC silicon issue or erratum?
* Are there shared resources between the 1G mEMAC ports that could cause loss of carrier on one port while transmitting to temporarily affect another port's TX FIFO?
* Is there a required sequence when a PHY loses link, such as stopping QMI dequeue, disabling the BMI TX port, disabling mEMAC TX/RX, or resetting the mEMAC?
* Is there any mEMAC or FMan status register that can detect the condition leading to `TX_FIFO_OVFL` before the overflow occurs?
* Are there recommended FMan/mEMAC or PHY configuration changes that might prevent `TX_FIFO_OVFL` in this situation?

Thanks

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

Hello,

There is no publicly documented T1040/FMan v3 silicon erratum that specifically describes TX_FIFO_OVFL on a healthy port triggered by link loss on a peer port. The T1040 Chip Errata document is NDA-controlled and not publicly indexed, but no such cross-port TX FIFO overflow erratum has been identified for the T1040 mEMAC.

The behavior you are observing is most likely an architectural interaction within the shared FMan BMI resources rather than a silicon defect.

Regards

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

Thanks. Can you identify which shared BMI resource or arbitration mechanism is expected to cause this behavior?

I have tested changes to FMBM_PFS[IFSZ], FMBM_TFP[DPDE], and FMBM_TFP[FLCL] without seeing a meaningful change. I also stop enqueueing and disable mEMAC TX immediately when IF_STATUS[RGLINK] goes low, but the healthy port can still lose packets.

Is there a documented or recommended configuration to isolate the ports from this interaction? Also, is there a counter, status register, or debug mechanism that can show which BMI resource is becoming exhausted, blocked, or otherwise preventing the healthy mEMAC from draining its TX FIFO?

Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link

Hi,

The four shared BMI resources are TNUMs (tasks), DMA channels, FIFO (MURAM), and pipeline-depth. Since your FIFO size, pipeline depth (DPDE), and FIFO low threshold (FLCL) changes produced no improvement, the DMA channel layer is the most likely bottleneck, not MURAM allocation.

The T1040 FMan has a fixed pool of DMA channels shared across all active TX ports. The TX path for each port is:

CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire

When your stalled port loses link and you clear COMMAND_CONFIG[TX_EN], the mEMAC stops transmitting to the wire, but any frames that are already mid-pipeline — specifically those for which the BMI TX port has already issued a DMA read transaction (DDR → MURAM TX FIFO) — do not immediately complete. The DMA read may have already moved data into the TX FIFO, and the FMan DMA engine is now waiting for a "DMA complete / EBD (external buffer descriptor) release" acknowledgment that depends on the MAC consuming the FIFO. With TX_EN=0, the MAC is not consuming, so the DMA transaction stays open.

Those open DMA transactions on the stalled port hold shared DMA channel slots. Under high load, the healthy port's BMI TX path cannot acquire enough DMA channel slots to fetch data from DDR quickly enough to keep its TX FIFO supplied → the TX FIFO goes empty briefly → then backfills faster than the MAC drain rate → TX_FIFO_OVFL.

Regards