arge problem on MR3420

[Adrian Chadd]

On 31 December 2011 04:36, Stefan Bethke <stb at lassitu.de> wrote:
> Am 30.12.2011 um 23:49 schrieb Stefan Bethke:
>
>> OK, trying to pull in everyone.  There seems to be a problem with if_arge on certain chips/platforms.  I've encountered it on TL-MR3420 and WRT-160NL.  I'm currently working off Adrians gitorious repo.
>
> The problem is limited to BOOTP; if I mount a USB stick as root, I can bring up arge1 without issue.
>
> On the AR7241, arge0 is connected to a phy and the blue WAN port, arge1 is connected to the built-in switch.  The port speeds are fixed (1000 for the switch, 100 for the phy).
>
> With BOOTP enabled, I'm getting an interrupt storm on intr 3.  I've enabled debugging for arge, and it seems there is a TX underrun that is not being cleared in that case.  I'm not fully understanding the code, so I'm not sure why the TX underrun is not being cleared, or keeps reoccurring.

Is the bootp code somehow tickling the interface setup in a way that
isn't the same as the userland-driven config?

Ie, a tx underrun should only occur if it runs out of TX descriptor
slots. That's fine, it just means that it go to the end of the
descriptor list. It's not _necessarily_ an error condition.

And it should only _keep_ occuring if someone/something keeps tickling
the DMA_TX_CONTROL_EN bit.

So when the underrun occurs, what's the state of the TX ring head/tail pointers?

The code in arge_intr() should be self explanatory. If any frames were
sent, call arge_start_locked(). The call to arge_encap() throws
something into the TX ring and then sets DMA_TX_CONTROL_EN.

How about adding a printf() to arge_start_locked() and arge_encap(),
see if they're constantly being called.


Adrian