RTEMS 4.X.X gen68360 Ethernet Tx Reliability

Bob Wisdom bobwis at ascweb.co.uk
Tue Feb 8 15:07:36 UTC 2000

Ok, many thanks for the interest, info and help!. Are you saying that you
tried the modified UDP testing with the current driver and it passed?

Unfortunately we came off the TCP testing to backtrack onto the UDP test
(modified) as it blows up on our board and no one can explain why, plus I
don't think anyone else has yet seen the problem. We still can't determine
if it's our target, or what it is. Strangely we have a modified driver that
won't yet fail, but we can't explain why it works any better than the
previous one.

Our target falls over very quickly with the original driver with just the
UDP test modified a bit (It passes with the unmodified UDP test). We are
trying to get to the bottom of it and I have just written, excuse me! I
should say *hacked* together a new section for the UDP test with a random
number of loops, buffer sizes and delays.

We can try it on the TCP test later as well. So far (early days) with the
new driver the target stays working and with the original it croaks. The
Author, Eric Norum who has done loads of contributions to RTEMS, is kindly
looking into the situation and we are really trying to come to a firm
conclusion ASAP.

-----Original Message-----
From: Nick.SIMON at syntegra.bt.co.uk [mailto:Nick.SIMON at syntegra.bt.co.uk]
Sent: Tuesday, February 08, 2000 11:05 AM
To: bobwis at ascweb.co.uk
Cc: rtems-users at OARcorp.com
Subject: RE: RTEMS 4.X.X gen68360 Ethernet Tx Reliability

I ran into this one last week (as a result of duplicating your test).
man bind(2) says:

                                                        For TCP a
       bound  local  socket  endpoint  (address/port   pair)   is
       unavailable for some time after closing the socket, unless
       the SO_REUSEADDR flag is set. Note that carelessly setting
       SO_REUSEADDR might make TCP more unreliable unless PAWS is
       used (see tcp(4)); the delay is needed to handle old pack
       ets still in the network.

So there!  tcptest really shouldn't bomb out when bind fails.


-- Nick Simon

> -----Original Message-----
> From: Bob Wisdom [mailto:bobwis at ascweb.co.uk]
> Sent: 04 February 2000 16:42
> To: 'rtems mail-list'
> Subject: RTEMS 4.X.X gen68360 Ethernet Tx Reliability
> Clues and Red Herrings!
> -----------------------------------
> We have discovered that if we negate the code which attempts
> to skip empty
> MBUFs we can achieve reliable transmission. Obviously, one
> cannot allow the
> SCC to try and send a zero length buffer, so we implemented a
> little in-line
> "scatter" function which split the previous SCC TX buffer
> into two, thus
> filling the TX buffer which would have corresponded to the
> zero length MBUF.
> Bingo, it all seems to work ok. Anyone got any ideas why? -
> we have sent
> hundreds of Megabytes using buffer sizes > 1500 which was
> impossible before,
> it hasn't failed yet.
> Next problem - or maybe ignorance on my part more likely. The
> netdemo prog
> has a TCP test. You type "t" to start it. We set up our Linux
> box to act as
> a packet dump on the discard port and we find that we can
> only run the test
> every couple of minutes. If we try to repeat it too quickly
> we get an error
> which says "Can't bind to socket". Is this a TCP phenomenon?
> Bob Wisdom
> bobwis at ascweb.co.uk

More information about the users mailing list