This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: "packets eaten" with AT91 EMAC Ethernet driver



> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: maandag 9 juni 2008 17:32
> To: Lambrecht Jürgen
> Cc: ecos-discuss@ecos.sourceware.org; I-Yanaslov
> Subject: Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver
> 
> On Mon, Jun 09, 2008 at 05:19:02PM +0200, J?rgen Lambrecht wrote:
> > Hello,
> >
> > Since I solved the bugs in the AT91 EMAC driver
> > (RX: reset of ?bytes_in_list? (position in current sg_list))(TX: at
> > TXERR IRQ, reset SW pointer; set all used bits to 0 instead of 1),
> > I always had the same problem: after a while of communicating over
> > Ethernet with the AT91 EMAC, packets get ?eaten?.
> >
> > TX Packets get stuck, and they need an RX packet to get out.
> 
> It sounds like missed interrupts, or a race condition in the interrupt
> handling.
Yes indeed.
The original driver does not mask interrupts at the start of the ISR and unmask them at the end of the DSR.
Is it correct that this mask/unmask is not needed because it is an internal interrupt and at the end of the ISR 'cyg_interrupt_acknowledge(vector)' is called - this acknowledge clears the interrupt? So this should be ok.

Maybe there is a sort of race condition with can_send()?


> 
> You might be interested in looking at the Linux drivers/net/macb.c
> file. This is i think the Linux driver for the EMAC. It might give you
Indeed. I'll do.

> some clues. It is interesting that they initialize all the TX buffers
> as being used, the opposite to what you do.

Yes, the original driver did the same.
But the datasheet (section 36.4.1.3 for SAM9260 vG and 37.4.1.3 for SAM7 vG point 2) is clear about this. 
I actually think it is an error in the datasheet, because my driver causes an "error" (TXERR IRQ with BEX (buffers exhausted)). With all TX buffers marked being used (original driver), you only get an UND (underrun) "warning" (UND in TSR is set, but no TXERR IRQ).
But Atmel will have to clarify this.
> 
>      Andrew

Thanks,
Jürgen

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]