Hello, On Wed, Nov 8, 2017 at 10:56 PM, Kristian Evensen <kristian.even...@gmail.com> wrote: > I have been trying to solve this myself for a couple of days, but I am > starting to run out of idea. Could it be that there is some traffic > destined for the client (via. the 2626) that gets stuck in the TX > queue on the 3526? Any help, pointers on where to look or ideas for > what could be wrong would be much appreciated.
I have been doing some more debugging during the day today, and it seems that the problem is that the hardware for some reason stops transmitting data. I dumped the content of the TX ring on every timeout, and the output seems to indicate that the state of the ring is sane. For example, with the following error: [ 325.650638] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out [ 325.656857] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000067 [ 325.662902] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0ef58000, max=512, ctx=384, dtx=0, fdx=0, next=384 [ 325.673234] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0ef5e000, max=512, calc=5, drx=6 I see that the CPU txds [384-511] have DDONE set and no SKB, while DDONE is not set for the DMA txds [0-383] and an skb is attached. I also looked at the content of the skb, and as far as I can see it is valid. Looking at the content of the SKB also shows that fe_reset_pending() does its job. For every timeout, there is a new set of packets on the ring. So new packets are put on the ring, but none are sent. -Kristian _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
