arge problem on MR3420

[Stefan Bethke]

Am 31.12.2011 um 17:01 schrieb 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.

I'll do that next year :-)

I believe the BOOTP code starts before timers are running, would that affect things?


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811