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: eth_recv out of MBUFs


(try again to send to ecos)

On 07/20/2011 09:15 PM, Stanislav Meduna wrote:
>
> Hi,
>
> I am quite reproducibly able to produce
>
>   eth_recv out of MBUFs
>
> in the FreeBSD stack. The setup is two incoming TCP connections
> sending data, a UDP socket sending data, pinging the device,
> closing and reopening the TCP connections a few times and
> to pull and put back the ethernet cable.
>
Be carefull: the eCos freeBSD stack has no timeouts on TCP connections I 
believe, but often the PC stack has!
So the eCos TCP session stays alive, but the PC (used to test) stack 
shuts down the TCP connection when the cable breaks (after a timeout, or 
it can also detect the cable fault). And the TCPs are out of sync 
(something like that), and then it uses a lot of sockets, and indeed (as 
in your next mail) the timeouts are very big to free sockets.
If that is your problem, I can ask my college: he recompiled ecos to 
change the minute timeout to seconds.
>
>
> The device then never recovers. The partner sends ARP requests
> with no response from eCos, as there is no mbuf to accept them.
> The eCos never send anything. eth_drv_tickle_devices runs, but
> finds IF_IS_EMPTY(&ifp->if_snd) true and never touches
> the interface. Maybe it wants to ARP first, but was unable
> to send the request - I don't know. Unless I am blind
> I am caling tx_done for every packet I got into send
> (but I am going to double-check this).
>
> The mbufs as shown by cyg_net_show_mbufs are full of DATA
> with short size (60 or 64) and flags 2 (M_PKTHDR).
>
> Anyone has seen something like that? I am not very familiar
> with the TCP/IP stacks in general - so it is quite problematic
> for me to debug something there. Are there some constraints
> of the "mbuf space has to be larger than tcp window of active
> connections" type or something like that?
>
> I am reluctant to try to "fix" it enlarging the space for mbufs,
> as I think this should never happen regardless of mbufs and I am
> also on a quite memory-constrained device where every 100 kB
> matter.
>
With a slow device and big burst of data, I had to increase the space 
for mbufs.
I have had some problems with segmented data (using IP packets of > 
1518B(-header sizes)), but I believe the freeBSD stack is OK.

Better use lwIP on memory-constrained devices. And lwIP is more actively 
maintained..

Success,
Jürgen
>
>
> Thanks for any hints
> --
>                                        Stano
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


-- 
Jürgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045    Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk

--
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]