arge1 on TL WDR3600

[Adrian Chadd]

This may actually be a bug in how the rx/tx descriptors are handled.

I'm going to have to change it to pad them out to be one descriptor
per cache line. It's the only way this'll work.



-a


On 29 October 2015 at 14:41, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> AH, ok. So it says TX_UNDERRUN + TX_PKT_SENT. So hm.
>
> The way this is supposed to work is .. odd.
>
> You queue TX packets to the hardware. The hardware increments
> TXPKTCOUNT in the TX DMA status register.
>
> Then for each packet you see transmitted, you write TXPKTSENT to the
> TX DMA status register and that decrements TXPKTCOUNT. Once it's zero,
> you won't see any more TX interrupts.
>
> Now, the 'arge_tx_cnt' value tracks that; it should be zero if it's
> idle. It's 126, which means there are still things to process. there's
> 128 ring slots, so that prod/cons value indicates there's 126 things
> in the ring. arge_tx_locked() does the decrementing and poking
> TXPKTSENT.
>
> So, I bet the driver and hardware is out of sync. I bet that the (ctrl
> & ARGE_DESC_EMPTY) check is triggering on the current frame in that
> ring. I don't know if it's because prod/cons are out of whack, or it's
> currently trying to check a descriptor in a multi-frame TX descriptor,
> or whether the hardware is just plain buggy and it didn't update that.
> But, that's actually what's going on.
>
> So that's my 5 minute analysis of it. I wish I could reproduce it on
> what I have here because then I could see what the state of the ring
> is and whether the hardware is buggy or our tx prod/cons tracking is
> busted. I'd reaally appreciate help here :(
>
>
> -adrian