[ECOS] "packets eaten" with AT91 EMAC Ethernet driver
Tue Jun 10 16:11:00 GMT 2008
Lambrecht JÃ¼rgen wrote:
>> -----Original Message-----
>> From: Andrew Lunn [mailto:firstname.lastname@example.org]
>> Sent: maandag 9 juni 2008 17:32
>> To: Lambrecht JÃ¼rgen
>> Cc: email@example.com; 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:
>>> 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
> 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()?
Indeed, that was the problem:
Wrong code in at91_eth_deliver():
if (tsr&AT91_EMAC_TSR_COMP) //5
priv->tx_busy = false;
priv->tx_busy = false;
Aparantly very few people know how the complete TCP/IP stack works in
eCos.... I also did not knew it, now I know:
The high-level TCP/IP stack puts al its data in a buffer, and calls once
the "middleware" /io/eth/current/src/net/eth_drv.c::eth_drv_send() function.
If the low-level driver is available (can_send() returns not zero) then
the first packet is sent.
If the low-level driver is not available it stops here. It is supposed
that the low-level driver will inform then the middleware when it is
ready by calling tx_done.
eth_drv_tx_done on its turn calls eth_drv_send() which then checks again
The AT91 driver first called tx_done, calling send calling can_send
which returns 0 of course.
And afterwards - too late - busy is set to true, so that can_send can
Missing a TX interrupt is fatal..
Then the option CYGPKG_NET_FAST_THREAD_TICKLE_DEVS is very handy
(default on option!)! But this unblocks only an already blocked driver..
Mark that for LW-IP and Redboot there are other drivers there.
P.S.: my troubles are not yet finished; I have RX BNA problems now..
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss