* [ECOS] Re: cyg_selwakeup and performance impact? @ 2008-10-19 15:05 Tom Anderson 2009-02-08 14:17 ` Zhichao Hong 0 siblings, 1 reply; 13+ messages in thread From: Tom Anderson @ 2008-10-19 15:05 UTC (permalink / raw) To: zhichao.hong; +Cc: ecos-discuss >> 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ECOS] Re: cyg_selwakeup and performance impact? 2008-10-19 15:05 [ECOS] Re: cyg_selwakeup and performance impact? Tom Anderson @ 2009-02-08 14:17 ` Zhichao Hong 2009-02-09 16:05 ` [ECOS] Debug eCos kernel Deroo Stijn 0 siblings, 1 reply; 13+ messages in thread From: Zhichao Hong @ 2009-02-08 14:17 UTC (permalink / raw) To: Tom Anderson; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ECOS] Debug eCos kernel 2009-02-08 14:17 ` Zhichao Hong @ 2009-02-09 16:05 ` Deroo Stijn 2009-02-09 16:40 ` Gary Thomas 0 siblings, 1 reply; 13+ messages in thread From: Deroo Stijn @ 2009-02-09 16:05 UTC (permalink / raw) To: ecos-discuss; +Cc: andrew 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ECOS] Debug eCos kernel 2009-02-09 16:05 ` [ECOS] Debug eCos kernel Deroo Stijn @ 2009-02-09 16:40 ` Gary Thomas 2009-02-09 18:02 ` Andrew Lunn 0 siblings, 1 reply; 13+ messages in thread From: Gary Thomas @ 2009-02-09 16:40 UTC (permalink / raw) To: Deroo Stijn; +Cc: ecos-discuss, andrew 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ECOS] Debug eCos kernel 2009-02-09 16:40 ` Gary Thomas @ 2009-02-09 18:02 ` Andrew Lunn 2009-02-10 7:19 ` Deroo Stijn 0 siblings, 1 reply; 13+ messages in thread From: Andrew Lunn @ 2009-02-09 18:02 UTC (permalink / raw) To: Gary Thomas; +Cc: Deroo Stijn, ecos-discuss, andrew 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [ECOS] Debug eCos kernel 2009-02-09 18:02 ` Andrew Lunn @ 2009-02-10 7:19 ` Deroo Stijn 2009-02-10 7:37 ` Andrew Lunn 0 siblings, 1 reply; 13+ messages in thread From: Deroo Stijn @ 2009-02-10 7:19 UTC (permalink / raw) To: Andrew Lunn, Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ECOS] Debug eCos kernel 2009-02-10 7:19 ` Deroo Stijn @ 2009-02-10 7:37 ` Andrew Lunn 2009-02-10 15:43 ` Deroo Stijn 0 siblings, 1 reply; 13+ messages in thread From: Andrew Lunn @ 2009-02-10 7:37 UTC (permalink / raw) To: Deroo Stijn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [ECOS] Debug eCos kernel 2009-02-10 7:37 ` Andrew Lunn @ 2009-02-10 15:43 ` Deroo Stijn 2009-02-10 16:15 ` Andrew Lunn 0 siblings, 1 reply; 13+ messages in thread From: Deroo Stijn @ 2009-02-10 15:43 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ECOS] Debug eCos kernel 2009-02-10 15:43 ` Deroo Stijn @ 2009-02-10 16:15 ` Andrew Lunn 2009-02-11 9:55 ` Deroo Stijn 0 siblings, 1 reply; 13+ messages in thread From: Andrew Lunn @ 2009-02-10 16:15 UTC (permalink / raw) To: Deroo Stijn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [ECOS] Debug eCos kernel 2009-02-10 16:15 ` Andrew Lunn @ 2009-02-11 9:55 ` Deroo Stijn 2009-02-11 10:09 ` Andrew Lunn 0 siblings, 1 reply; 13+ messages in thread From: Deroo Stijn @ 2009-02-11 9:55 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ECOS] Debug eCos kernel 2009-02-11 9:55 ` Deroo Stijn @ 2009-02-11 10:09 ` Andrew Lunn 2009-02-11 10:38 ` [ECOS] " Daniel Néri 0 siblings, 1 reply; 13+ messages in thread From: Andrew Lunn @ 2009-02-11 10:09 UTC (permalink / raw) To: Deroo Stijn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ECOS] Re: Debug eCos kernel 2009-02-11 10:09 ` Andrew Lunn @ 2009-02-11 10:38 ` Daniel Néri 2009-02-11 10:44 ` Daniel Néri 0 siblings, 1 reply; 13+ messages in thread From: Daniel Néri @ 2009-02-11 10:38 UTC (permalink / raw) To: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ECOS] Re: Debug eCos kernel 2009-02-11 10:38 ` [ECOS] " Daniel Néri @ 2009-02-11 10:44 ` Daniel Néri 0 siblings, 0 replies; 13+ messages in thread From: Daniel Néri @ 2009-02-11 10:44 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-02-11 10:44 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-19 15:05 [ECOS] Re: cyg_selwakeup and performance impact? Tom Anderson 2009-02-08 14:17 ` Zhichao Hong 2009-02-09 16:05 ` [ECOS] Debug eCos kernel Deroo Stijn 2009-02-09 16:40 ` Gary Thomas 2009-02-09 18:02 ` Andrew Lunn 2009-02-10 7:19 ` Deroo Stijn 2009-02-10 7:37 ` Andrew Lunn 2009-02-10 15:43 ` Deroo Stijn 2009-02-10 16:15 ` Andrew Lunn 2009-02-11 9:55 ` Deroo Stijn 2009-02-11 10:09 ` Andrew Lunn 2009-02-11 10:38 ` [ECOS] " Daniel Néri 2009-02-11 10:44 ` Daniel Néri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).