This is the mail archive of the ecos-patches@sources.redhat.com 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: bsd_tcpip patch for false positive assert


Øyvind Harboe wrote:
On Thu, 2004-04-29 at 09:04, Jonathan Larmour wrote:

Øyvind Harboe wrote:

Did I get this right?
Index: current/src/ecos/timeout.c
===================================================================
RCS file: /cvs/ecos/ecos-opt/net/net/bsd_tcpip/current/src/ecos/timeout.c,v
retrieving revision 1.3
diff -u -r1.3 timeout.c
--- current/src/ecos/timeout.c	12 May 2003 11:03:06 -0000	1.3
+++ current/src/ecos/timeout.c	20 Apr 2004 07:45:41 -0000
@@ -402,8 +402,10 @@
        for (e = timeouts;  e;  e = e->next) {
            if (e->delta) {
                CYG_ASSERT( e->delta >= last_delta, "e->delta underflow" );
-                CYG_ASSERT( last_set_time + e->delta + 1000 > now,
-                            "Recorded alarm not in the future!" );
+                // The alert below may yields false positives since on slow CPU's
+                // it might simply be a matter of not enough CPU to process everything
+                // CYG_ASSERT( last_set_time + e->delta + 1000 > now,
+                //             "Recorded alarm not in the future!" );
                if ( e->delta < delta )
                    delta = e->delta;
            } else {

This should be the number of ticks I believe, so assuming 10 milliseconds ticks, 1000 corresponds to 1000* 10 milliseconds, i.e. 10 seconds. Are you sure this can happen under normal circumstances?


Even if I'm wrong, wouldn't it be better just to choose a larger value than 1000?


If there is a real problem, I don't speak bsd_tcpip and PPP well enough
to figure it out at the moment. The assert fails during normal execution
of PPP on an EB40a.

It's possible the network thread is getting starved by some thread in the rest of the system (or possibly the serial processing overhead + pppd processing time result in something leaving little time for much else). But in that case I'd still say there is a problem, because starving the network thread can't be a good thing. 10 seconds is a long time if that's what it is.


Or of course there could be a bug, in which case removing the assert is still wrong :).

I see no other ill effects, except for the accept()/select() issue
against Windows PPP servers, but that happens much later so I assumed it
was unrelated.


My current PPP EB40a efforts have ground to a halt ref lots of earlier
mails and patches(Nick unstuck me a couple of times).

Can't help sorry. If I was mercenary I'd mention the possibility of getting commercial support ;).


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


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