[ECOS] Re: cyg_selwakeup and performance impact?

[ECOS] Re: cyg_selwakeup and performance impact?

[Tom Anderson]

>> serial_rcv_char() that wake up the thread in serial.c:
>>    //if( cbuf->nb == 0 )
>>        cyg_selwakeup( &cbuf->selinfo );

> Surely the best thing is to find out why that thread isn't getting woken up
when there's data?

For whatever
 problem you are trying to address, this kind of "fix" will cause more troubles than it helps.
Select only tells you that something available (readable) in your case.  Once you passed the
select, the best thing is to read the buffer empty.  And that is one of the reason you are selecting anyway.
One thing you can check is why the read did not read all the data it needs before put back to select again.
Is the read interrupted by signals or something else?

Actually if this is the cause, changing the eCos as you've shown will not actually help.  Even when it works, it is merely
a luck in a noisy system (many wake-ups) as you mentioned.  But these many wake-ups may still be not enough.  Or you could
see some odd issue in "unrelated" area.

I also think the best way is to address the application issue.  And I believe, changing eCos in this way will make
your application very hard to port to future releases or similar UNIX like
 OSes.

Just my 2 cents.

-Tom


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

[ECOS] Re: cyg_selwakeup and performance impact?

[Zhichao Hong]

The root cause of this problem has been fixed in the latest serial.c
rev 1.28.  The problem is caused by race condition in the
serial_select.  The problem is not about "draining the input buffer".
And the unnecessary wake up is not needed.  Glad that I don't have to
worry about the performance (thread rescheduling) penalty and its
unknown consequences.  Sorry about the confusion.

Zhichao
Zhichao Hong, CSDP
zhichao.hong@computer.org



On Sat, Oct 18, 2008 at 9:57 PM, Tom Anderson <anderson.tom38@yahoo.com> wrote:
>>> serial_rcv_char() that wake up the thread in serial.c:
>>>    //if( cbuf->nb == 0 )
>>>        cyg_selwakeup( &cbuf->selinfo );
>
>> Surely the best thing is to find out why that thread isn't getting woken up
> when there's data?
>
> For whatever
>  problem you are trying to address, this kind of "fix" will cause more troubles than it helps.
> Select only tells you that something available (readable) in your case.  Once you passed the
> select, the best thing is to read the buffer empty.  And that is one of the reason you are selecting anyway.
> One thing you can check is why the read did not read all the data it needs before put back to select again.
> Is the read interrupted by signals or something else?
>
> Actually if this is the cause, changing the eCos as you've shown will not actually help.  Even when it works, it is merely
> a luck in a noisy system (many wake-ups) as you mentioned.  But these many wake-ups may still be not enough.  Or you could
> see some odd issue in "unrelated" area.
>
> I also think the best way is to address the application issue.  And I believe, changing eCos in this way will make
> your application very hard to port to future releases or similar UNIX like
>  OSes.
>
> Just my 2 cents.
>
> -Tom
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>

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

[ECOS] Debug eCos kernel

[Deroo Stijn]

Hi,

I tried to debug the eCOS kernel by enabling the flag CYGIMPL_TRACE_SPLX as mentioned in http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg06087.html

However, I couldn't find the location where to enable this flag.  Even when I define this flag in param.h, the compilation fails.

Does someone knows how and where to enable this flag in order to debug the kernel?

Thanks,
Stijn.

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

Re: [ECOS] Debug eCos kernel

[Gary Thomas]

Deroo Stijn wrote:
> Hi,
> 
> I tried to debug the eCOS kernel by enabling the flag CYGIMPL_TRACE_SPLX as mentioned in http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg06087.html
> 
> However, I couldn't find the location where to enable this flag.  Even when I define this flag in param.h, the compilation fails.
> 
> Does someone knows how and where to enable this flag in order to debug the kernel?

What exactly are you trying to debug?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Re: [ECOS] Debug eCos kernel

[Andrew Lunn]

On Mon, Feb 09, 2009 at 09:40:02AM -0700, Gary Thomas wrote:
> Deroo Stijn wrote:
> > Hi,
> > 
> > I tried to debug the eCOS kernel by enabling the flag CYGIMPL_TRACE_SPLX as mentioned in http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg06087.html
> > 
> > However, I couldn't find the location where to enable this flag.  Even when I define this flag in param.h, the compilation fails.
> > 
> > Does someone knows how and where to enable this flag in order to debug the kernel?
> 
> What exactly are you trying to debug?

The wrong thing, i think! CYGIMPL_TRACE_SPLX is for the mutual
exclusion primitives in the TCP/IP stack, ie nothing to do with the
kernel.

        Andrew

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

RE: [ECOS] Debug eCos kernel

[Deroo Stijn]

Ok, sorry about that, but I want indeed investigate the mutual exclusion to see where it goes wrong for my application.  So I still don't know how to enable these debugging?

KR,
Stijn.

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
> Sent: maandag 9 februari 2009 19:03
> To: Gary Thomas
> Cc: Deroo Stijn; ecos-discuss@sourceware.org; andrew@lunn.ch
> Subject: Re: [ECOS] Debug eCos kernel
>
> On Mon, Feb 09, 2009 at 09:40:02AM -0700, Gary Thomas wrote:
> > Deroo Stijn wrote:
> > > Hi,
> > >
> > > I tried to debug the eCOS kernel by enabling the flag
> CYGIMPL_TRACE_SPLX as mentioned in http://www.mail-archive.com/ecos-
> discuss@ecos.sourceware.org/msg06087.html
> > >
> > > However, I couldn't find the location where to enable this flag.  Even
> when I define this flag in param.h, the compilation fails.
> > >
> > > Does someone knows how and where to enable this flag in order to debug
> the kernel?
> >
> > What exactly are you trying to debug?
>
> The wrong thing, i think! CYGIMPL_TRACE_SPLX is for the mutual
> exclusion primitives in the TCP/IP stack, ie nothing to do with the
> kernel.
>
>         Andrew
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] Debug eCos kernel

[Andrew Lunn]

On Tue, Feb 10, 2009 at 08:18:56AM +0100, Deroo Stijn wrote:

> Ok, sorry about that, but I want indeed investigate the mutual
> exclusion to see where it goes wrong for my application.  So I still
> don't know how to enable these debugging?

Are you trying to debug problems with the eCos kernel, or the eCos
networking stack. They are two very different things.

Deadloads and things like that can be very hard to debug since they
are very timing dependent. Changing the code changes the timing and
the problem goes away... 

Anyway, first thing is to make sure you have asserts enabled:

CYGPKG_INFRA_DEBUG

and asserts will automatically be enabled. 

Then take a look at:

http://ecos.sourceware.org/docs-latest/user-guide/debugging-techniques.html

        Andrew

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

RE: [ECOS] Debug eCos kernel

[Deroo Stijn]

Ok, I enabled CYGPKG_INFRA_DEBUG and can see a lot of extra info, but I'm still not able to see what I need.  I looked further into http://ecos.sourceware.org/docs-latest/user-guide/debugging-techniques.html but don't see how this will enable the CYGIMPL_TRACE_SPLX flag.

I need to know which thread/process is blocking the mutex 'splx_mutex' in synch.c (spl_any()), because at a certain time, the thread 'Network alarm support' is blocking on this mutex.

Enabling CYGIMPL_TRACE_SPLX and calling show_sched_events() should answer this, but I really can't find where to enable this?

Kind regards,
Stijn.

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: dinsdag 10 februari 2009 8:38
> To: Deroo Stijn
> Cc: ecos-discuss@sourceware.org
> Subject: Re: [ECOS] Debug eCos kernel
>
> On Tue, Feb 10, 2009 at 08:18:56AM +0100, Deroo Stijn wrote:
>
> > Ok, sorry about that, but I want indeed investigate the mutual
> > exclusion to see where it goes wrong for my application.  So I still
> > don't know how to enable these debugging?
>
> Are you trying to debug problems with the eCos kernel, or the eCos
> networking stack. They are two very different things.
>
> Deadloads and things like that can be very hard to debug since they
> are very timing dependent. Changing the code changes the timing and
> the problem goes away...
>
> Anyway, first thing is to make sure you have asserts enabled:
>
> CYGPKG_INFRA_DEBUG
>
> and asserts will automatically be enabled.
>
> Then take a look at:
>
> http://ecos.sourceware.org/docs-latest/user-guide/debugging-
> techniques.html
>
>         Andrew

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

Re: [ECOS] Debug eCos kernel

[Andrew Lunn]

On Tue, Feb 10, 2009 at 04:43:01PM +0100, Deroo Stijn wrote:
> Ok, I enabled CYGPKG_INFRA_DEBUG and can see a lot of extra info, but I'm still not able to see what I need.  I looked further into http://ecos.sourceware.org/docs-latest/user-guide/debugging-techniques.html but don't see how this will enable the CYGIMPL_TRACE_SPLX flag.
> 
> I need to know which thread/process is blocking the mutex 'splx_mutex' in synch.c (spl_any()), because at a certain time, the thread 'Network alarm support' is blocking on this mutex.
> 
> Enabling CYGIMPL_TRACE_SPLX and calling show_sched_events() should answer this, but I really can't find where to enable this?

Ah, so you really do want to debug the TCP/IP stack. When you said you
wanted to debug the kernel i thought you really did want to debug the
kernel, not the TCP/IP stack. 

So enable CYGIMPL_TRACE_SPLX and then call show_sched_events() every
so often, especially after your system has deadlocked or done whatever
it does.

   Andrew

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

RE: [ECOS] Debug eCos kernel

[Deroo Stijn]

Andrew,

I enabled CYGIMPL_TRACE_SPLX, but I can't compile ecos correctly.  It's giving me following error.  I doubt if the right place to enable CYGIMPL_TRACE_SPLX is in param.h?

/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
37:29: macro "cyg_scheduler_lock" passed 1 arguments, but takes just 0
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
39:31: macro "cyg_scheduler_unlock" passed 1 arguments, but takes just 0
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
44:34: macro "cyg_scheduler_safe_lock" passed 1 arguments, but takes just 0
In file included from /ecos-c/version/vcs/c/ims/std_ims/ecos/packages/io/eth/current/src/net/eth_drv
.c:88:
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/hal/hal_if.h: I
n function `__call_COMM_IF_WRITE':
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/hal/hal_if.h:29
3: warning: implicit declaration of function `_cyg_scheduler_lock'
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/hal/hal_if.h:29
3: warning: implicit declaration of function `_cyg_scheduler_unlock'
/ecos-c/version/vcs/c/ims/std_ims/ecos/packages/io/eth/current/src/net/eth_drv.c: At top level:
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
37: storage size of `cyg_scheduler_lock' isn't known
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
39: storage size of `cyg_scheduler_unlock' isn't known
/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
44: storage size of `cyg_scheduler_safe_lock' isn't known
make[2]: *** [src/net/eth_drv.o.d] Error 1
make[2]: Leaving directory `/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/io/eth/
current'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg'
make: *** [build_ecos] Error 2

KR,
Stijn.

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: dinsdag 10 februari 2009 17:15
> To: Deroo Stijn
> Cc: ecos-discuss@sourceware.org
> Subject: Re: [ECOS] Debug eCos kernel
>
> On Tue, Feb 10, 2009 at 04:43:01PM +0100, Deroo Stijn wrote:
> > Ok, I enabled CYGPKG_INFRA_DEBUG and can see a lot of extra info, but
> I'm still not able to see what I need.  I looked further into
> http://ecos.sourceware.org/docs-latest/user-guide/debugging-
> techniques.html but don't see how this will enable the CYGIMPL_TRACE_SPLX
> flag.
> >
> > I need to know which thread/process is blocking the mutex 'splx_mutex'
> in synch.c (spl_any()), because at a certain time, the thread 'Network
> alarm support' is blocking on this mutex.
> >
> > Enabling CYGIMPL_TRACE_SPLX and calling show_sched_events() should
> answer this, but I really can't find where to enable this?
>
> Ah, so you really do want to debug the TCP/IP stack. When you said you
> wanted to debug the kernel i thought you really did want to debug the
> kernel, not the TCP/IP stack.
>
> So enable CYGIMPL_TRACE_SPLX and then call show_sched_events() every
> so often, especially after your system has deadlocked or done whatever
> it does.
>
>    Andrew

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

Re: [ECOS] Debug eCos kernel

[Andrew Lunn]

On Wed, Feb 11, 2009 at 10:54:53AM +0100, Deroo Stijn wrote:
> Andrew,
> 
> I enabled CYGIMPL_TRACE_SPLX, but I can't compile ecos correctly.  It's giving me following error.  I doubt if the right place to enable CYGIMPL_TRACE_SPLX is in param.h?
> 
> /ecos-c/version/vcs/c/dse-2001/ddvcs/build/ecos_7308_jtagram_dbg/install/include/cyg/kernel/kapi.h:1
> 37:29: macro "cyg_scheduler_lock" passed 1 arguments, but takes just 0

I'm not too supprised. This is debug code left over from when the
TCP/IP stack was first ported. I has probably not been used for 5 or
more years.

You are going to have to work on it before it will be
usable. Hopefully you can see the idea what it is trying to do.

    Andrew

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

[ECOS] Re: Debug eCos kernel

[Daniel Néri]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

Andrew Lunn <andrew@lunn.ch> writes:

> You are going to have to work on it before it will be
> usable. Hopefully you can see the idea what it is trying to do.

I did some of that work a while ago, but ended up not using it. I'm
attaching a patch with the changes I made to make the code compile
without errors (but no promises beyond that).

Regards,
Daniel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: trace-splx-fix.patch --]
[-- Type: text/x-patch, Size: 6017 bytes --]

diff --git a/net/bsd_tcpip/current/include/sys/param.h b/net/bsd_tcpip/current/include/sys/param.h
--- a/net/bsd_tcpip/current/include/sys/param.h
+++ b/net/bsd_tcpip/current/include/sys/param.h
@@ -815,9 +815,11 @@
 #define splclock() cyg_splclock(__FUNCTION__, __LINE__)
 #define splsoftnet() cyg_splsoftnet(__FUNCTION__, __LINE__)
 #define splx(x)    cyg_splx(x, __FUNCTION__, __LINE__)
+#if 0
 #define cyg_scheduler_lock() _cyg_scheduler_lock(__FUNCTION__, __LINE__)
 #define cyg_scheduler_safe_lock() _cyg_scheduler_safe_lock(__FUNCTION__, __LINE__)
 #define cyg_scheduler_unlock() _cyg_scheduler_unlock(__FUNCTION__, __LINE__)
+#endif
 #else
 extern cyg_uint32  cyg_splimp(void);
 extern cyg_uint32  cyg_splnet(void);
diff --git a/net/bsd_tcpip/current/src/ecos/synch.c b/net/bsd_tcpip/current/src/ecos/synch.c
--- a/net/bsd_tcpip/current/src/ecos/synch.c
+++ b/net/bsd_tcpip/current/src/ecos/synch.c
@@ -115,9 +115,10 @@
 
 
 #ifdef CYGIMPL_TRACE_SPLX   
+static void do_sched_event(const char *, const char *, int, void *, cyg_uint32);
 #define SPLXARGS const char *file, const int line
-#define SPLXMOREARGS , const char *file, const int line
-#define SPLXTRACE do_sched_event(__FUNCTION__, file, line, spl_state)
+#define SPLXMOREARGS , SPLXARGS
+#define SPLXTRACE do_sched_event(__FUNCTION__, file, line, __builtin_return_address(0), spl_state)
 #else
 #define SPLXARGS void
 #define SPLXMOREARGS
@@ -357,13 +358,15 @@
 #define MAX_SCHED_EVENTS 256
 static struct _sched_event {
     char *fun, *file;
-    int line, lock;
+    int line;
+    cyg_uint32 lock;
+    void *ret;
 } sched_event[MAX_SCHED_EVENTS];
 static int next_sched_event = 0;
 static int total_sched_events = 0;
 
 static void
-do_sched_event(char *fun, char *file, int line, int lock)
+do_sched_event(const char *fun, const char *file, int line, void *ret, cyg_uint32 lock)
 {
     struct _sched_event *se = &sched_event[next_sched_event];
     if (++next_sched_event == MAX_SCHED_EVENTS) {
@@ -373,6 +376,7 @@
     se->file = file;
     se->line = line;
     se->lock = lock;
+    se->ret = ret;
     total_sched_events++;
 }
 
@@ -390,7 +394,7 @@
     diag_printf("%d total scheduler events\n", total_sched_events);
     while (i != next_sched_event) {
         se = &sched_event[i];
-        diag_printf("%s - lock: %d, called from %s.%d\n", se->fun, se->lock, se->file, se->line);
+        diag_printf("%s - lock: %d, called from %s:%d @ %p\n", se->fun, se->lock, se->file, se->line, se->ret);
         if (++i == MAX_SCHED_EVENTS) i = 0;
     }
 }
@@ -401,21 +405,21 @@
 _cyg_scheduler_lock(char *file, int line)
 {
     cyg_scheduler_lock();
-    do_sched_event(__FUNCTION__, file, line, SPLX_TRACE_DATA());
+    do_sched_event(__FUNCTION__, file, line, __builtin_return_address(0), SPLX_TRACE_DATA());
 }
 
 void
 _cyg_scheduler_safe_lock(char *file, int line)
 {
     cyg_scheduler_safe_lock();
-    do_sched_event(__FUNCTION__, file, line, SPLX_TRACE_DATA());
+    do_sched_event(__FUNCTION__, file, line, __builtin_return_address(0), SPLX_TRACE_DATA());
 }
 
 void
 _cyg_scheduler_unlock(char *file, int line)
 {
     cyg_scheduler_unlock();
-    do_sched_event(__FUNCTION__, file, line, SPLX_TRACE_DATA());
+    do_sched_event(__FUNCTION__, file, line, __builtin_return_address(0), SPLX_TRACE_DATA());
 }
 #endif // CYGIMPL_TRACE_SPLX
 
diff --git a/net/bsd_tcpip/current/src/ecos/timeout.c b/net/bsd_tcpip/current/src/ecos/timeout.c
--- a/net/bsd_tcpip/current/src/ecos/timeout.c
+++ b/net/bsd_tcpip/current/src/ecos/timeout.c
@@ -74,7 +74,13 @@
 
 // ------------------------------------------------------------------------
 // This routine exists so that this module can synchronize:
+#ifdef CYGIMPL_TRACE_SPLX
+extern cyg_uint32  cyg_splinternal(const char *, int);
+#define splinternal() cyg_splinternal(__FUNCTION__, __LINE__)
+#else
 extern cyg_uint32 cyg_splinternal(void);
+#define splinternal() cyg_splinternal()
+#endif
 
 #ifdef TIMEOUT_DEBUG
 static void
@@ -213,7 +219,7 @@
 #endif // CYGPKG_NET_FAST_THREAD_TICKLE_DEVS
         CYG_ASSERT( !((~3) & x), "Extra bits" );
 
-        spl = cyg_splinternal();
+        spl = splinternal();
 
         CYG_ASSERT( 0 == spl, "spl nonzero" );
 
@@ -230,7 +236,7 @@
         if ( 1 & x )
             do_timeout();
 
-        cyg_splx(spl);
+        splx(spl);
     }
 }
 
@@ -272,7 +278,7 @@
 
     // this needs to be atomic - recursive calls from the alarm
     // handler thread itself are allowed:
-    int spl = cyg_splinternal();
+    int spl = splinternal();
 
     stamp = 0;  // Assume no slots available
     for (e = _timeouts, i = 0;  i < NTIMEOUTS;  i++, e++) {
@@ -285,7 +291,7 @@
             break;
         }
     }
-    cyg_splx(spl);
+    splx(spl);
     return stamp;
 }
 
@@ -298,7 +304,7 @@
 {
     int i;
     timeout_entry *e;
-    int spl = cyg_splinternal();
+    int spl = splinternal();
 
     for (e = _timeouts, i = 0; i < NTIMEOUTS; i++, e++) {
         if (e->delta && (e->fun == fun) && (e->arg == arg)) {
@@ -306,7 +312,7 @@
             break;
         }
     }
-    cyg_splx(spl);
+    splx(spl);
 }
 
 void 
@@ -318,7 +324,7 @@
 void 
 callout_reset(struct callout *c, int delta, timeout_fun *f, void *p) 
 {
-    int spl = cyg_splinternal();
+    int spl = splinternal();
 
     CYG_ASSERT( 0 < delta, "delta is right now, or even sooner!" );
 
@@ -431,20 +437,20 @@
         CYG_ASSERT( delta >= last_delta, "We didn't pick the smallest delta!" );
     }
 #endif
-    cyg_splx(spl);
+    splx(spl);
 }
 
 void 
 callout_stop(struct callout *c) 
 {
-    int spl = cyg_splinternal();
+    int spl = splinternal();
 
 #ifdef TIMEOUT_DEBUG
     diag_printf("%s(%p) = %x\n", __FUNCTION__, c, c->flags);
 #endif
     if ((c->flags & CALLOUT_PENDING) == 0) {
         c->flags &= ~CALLOUT_ACTIVE;
-        cyg_splx(spl);
+        splx(spl);
         return;
     }
     c->flags &= ~(CALLOUT_PENDING | CALLOUT_ACTIVE);
@@ -456,7 +462,7 @@
     } else {
         timeouts = c->next;
     }
-    cyg_splx(spl);
+    splx(spl);
 }
 
 int  

[-- Attachment #3: Type: text/plain, Size: 75 bytes --]


-- 
Daniel Néri <daniel.neri@sigicom.com>
Sigicom AB, Stockholm, Sweden


[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

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

[ECOS] Re: Debug eCos kernel

[Daniel Néri]

   Hi,

Hmm, something went wrong there, but the comments below were meant to
serve as introduction to the patch in that last message.

Regards,
Daniel


daniel.neri@sigicom.com (Daniel Néri) writes:

> Andrew Lunn <andrew@lunn.ch> writes:
>
>> You are going to have to work on it before it will be
>> usable. Hopefully you can see the idea what it is trying to do.
>
> I did some of that work a while ago, but ended up not using it. I'm
> attaching a patch with the changes I made to make the code compile
> without errors (but no promises beyond that).
>
> Regards,
> Daniel

-- 
Daniel Néri <daniel.neri@sigicom.com>
Sigicom AB, Stockholm, Sweden


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