* [ECOS] please help me @ 2001-08-02 22:09 A Shobhan 2001-08-03 5:31 ` Jonathan Larmour 0 siblings, 1 reply; 6+ messages in thread From: A Shobhan @ 2001-08-02 22:09 UTC (permalink / raw) To: ecos-discuss Hi, I have a multi threaded program consists of just two threads on ARM = 7TDMI SOC target. The program is running fine if the eCos is built with = "Bitmap Scheduler" option, I am able to create Mutex and = cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler = with Time Slicing Enabled" option the program is hanging at = cyg_mutex_init() and no thread is working. The cyg_thread_delay() is = also hanging.=20 Why the cyg_mutex_init() is hanging in Multi level scheduler and not in = Bitmap scheduler? Why cyg_thread_delay() is hanging in Multi level scheduler and not in = Bitmap scheduler? Please help. Thanks in advance... Shobhan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] please help me 2001-08-02 22:09 [ECOS] please help me A Shobhan @ 2001-08-03 5:31 ` Jonathan Larmour 2001-08-03 12:27 ` A Shobhan 0 siblings, 1 reply; 6+ messages in thread From: Jonathan Larmour @ 2001-08-03 5:31 UTC (permalink / raw) To: A Shobhan; +Cc: ecos-discuss A Shobhan wrote: > > Hi, > > I have a multi threaded program consists of just two threads on ARM = > 7TDMI SOC target. The program is running fine if the eCos is built with = > "Bitmap Scheduler" option, I am able to create Mutex and = > cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler = > with Time Slicing Enabled" option the program is hanging at = > cyg_mutex_init() and no thread is working. The cyg_thread_delay() is = > also hanging.=20 > > Why the cyg_mutex_init() is hanging in Multi level scheduler and not in = > Bitmap scheduler? > Why cyg_thread_delay() is hanging in Multi level scheduler and not in = > Bitmap scheduler? You've probably made some assumption somewhere that you wouldn't get timesliced. But without seeing the program, we can't tell for sure! Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] please help me 2001-08-03 5:31 ` Jonathan Larmour @ 2001-08-03 12:27 ` A Shobhan 2001-08-03 12:41 ` Jonathan Larmour 2001-08-03 13:36 ` [ECOS] mips_rm7000.ld and dwarf Chris Morrow 0 siblings, 2 replies; 6+ messages in thread From: A Shobhan @ 2001-08-03 12:27 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss [-- Attachment #1: Type: text/plain, Size: 1400 bytes --] hi iam here with attaching the file hello.c. This code is working with bitmap scheduler, but hanging if the eCos is build with multilevel scheduler. thanks ----- Original Message ----- From: "Jonathan Larmour" <jlarmour@redhat.com> To: "A Shobhan" <shobana@in.ceeyes.com> Cc: <ecos-discuss@sourceware.cygnus.com> Sent: Friday, August 03, 2001 6:00 PM Subject: Re: [ECOS] please help me > A Shobhan wrote: > > > > Hi, > > > > I have a multi threaded program consists of just two threads on ARM = > > 7TDMI SOC target. The program is running fine if the eCos is built with = > > "Bitmap Scheduler" option, I am able to create Mutex and = > > cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler = > > with Time Slicing Enabled" option the program is hanging at = > > cyg_mutex_init() and no thread is working. The cyg_thread_delay() is = > > also hanging.=20 > > > > Why the cyg_mutex_init() is hanging in Multi level scheduler and not in = > > Bitmap scheduler? > > Why cyg_thread_delay() is hanging in Multi level scheduler and not in = > > Bitmap scheduler? > > You've probably made some assumption somewhere that you wouldn't get > timesliced. But without seeing the program, we can't tell for sure! > > Jifl > -- > Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 > Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine > [-- Attachment #2: hello.c --] [-- Type: text/x-c, Size: 1659 bytes --] /* this is a simple hello world program */ #include <stdio.h> #include <cyg/kernel/kapi.h> /* now declare (and allocate space for) some kernel objects, like the two threads we will use */ cyg_thread thread_s[3]; /* space for two thread objects */ char stack[3][4096]; /* space for two 4K stacks */ /* now the handles for the threads */ cyg_handle_t simple_threadA, simple_threadB, simple_threadC; /* and now variables for the procedure which is the thread */ cyg_thread_entry_t simple_program; /* and now a mutex to protect calls to the C library */ cyg_mutex_t cliblock; void cyg_user_start(void) { cyg_mutex_init(&cliblock); cyg_thread_create(4, simple_program, (cyg_addrword_t) 0, "Thread A", (void *) stack[0], 4096, &simple_threadA, &thread_s[0]); cyg_thread_create(4, simple_program, (cyg_addrword_t) 1, "Thread B", (void *) stack[1], 4096, &simple_threadB, &thread_s[1]); cyg_thread_create(4, simple_program, (cyg_addrword_t) 2, "Thread C", (void *) stack[2], 4096, &simple_threadC, &thread_s[2]); cyg_thread_resume(simple_threadB); cyg_thread_resume(simple_threadC); cyg_thread_resume(simple_threadA); displayString("\r\nCalling Scheduler.... \r\n"); } extern cyg_uint32 tick_count; void simple_program(cyg_addrword_t data) { int message = (int) data; int delay; //cyg_thread_delay(10); while(1) { cyg_mutex_lock(&cliblock); //cyg_scheduler_lock(); diag_printf("Beginning execution; thread data is %d\r\n", data ); cyg_mutex_unlock(&cliblock); //cyg_scheduler_unlock(); //CYGACC_CALL_IF_DELAY_US(1000); cyg_thread_delay(100); //cyg_thread_yield(); } } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] please help me 2001-08-03 12:27 ` A Shobhan @ 2001-08-03 12:41 ` Jonathan Larmour 2001-08-03 13:36 ` [ECOS] mips_rm7000.ld and dwarf Chris Morrow 1 sibling, 0 replies; 6+ messages in thread From: Jonathan Larmour @ 2001-08-03 12:41 UTC (permalink / raw) To: A Shobhan; +Cc: ecos-discuss A Shobhan wrote: > > hi > iam here with attaching the file hello.c. This code is working with > bitmap scheduler, but hanging if the eCos is build with multilevel > scheduler. Works fine for me: murgh:~/ecc/obj/i386/linux$ ./foo Beginning execution; thread data is 1 Beginning execution; thread data is 2 Beginning execution; thread data is 0 Beginning execution; thread data is 1 Beginning execution; thread data is 2 Beginning execution; thread data is 0 Beginning execution; thread data is 1 Beginning execution; thread data is 2 Perhaps you changed something else in your configuration. One trick I use is to use "ecosconfig export" on a configuration to see what values are set other than to their default. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] mips_rm7000.ld and dwarf 2001-08-03 12:27 ` A Shobhan 2001-08-03 12:41 ` Jonathan Larmour @ 2001-08-03 13:36 ` Chris Morrow 2001-08-03 13:45 ` Jonathan Larmour 1 sibling, 1 reply; 6+ messages in thread From: Chris Morrow @ 2001-08-03 13:36 UTC (permalink / raw) To: ecos-discuss Gdb (version 5.0) does not find any debugging symbols when attaching to an image produced with mips_rm7000.ld. If I copy debugging section stuff from the v1.3.1 linker script and remove the new stuff, gdb does find debugging symbols. My guess is that a -gdwarf or one of the similar flags should be passed to gcc instead of just -g. I'm using gcc 2.96 and binutils version 010326 (with BFD 010326) Is this correct? Also how is gcc v3.0 working out? -- Chris Morrow YottaYotta Inc. email: cmorrow@yottayotta.com phone: (780) 989 6814 web: http: //www.yottayotta.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] mips_rm7000.ld and dwarf 2001-08-03 13:36 ` [ECOS] mips_rm7000.ld and dwarf Chris Morrow @ 2001-08-03 13:45 ` Jonathan Larmour 0 siblings, 0 replies; 6+ messages in thread From: Jonathan Larmour @ 2001-08-03 13:45 UTC (permalink / raw) To: Chris Morrow; +Cc: ecos-discuss Chris Morrow wrote: > > Gdb (version 5.0) does not find any debugging symbols when > attaching to an image produced with mips_rm7000.ld. If I copy > debugging section stuff from the v1.3.1 linker script and remove > the new stuff, gdb does find debugging symbols. > > My guess is that a -gdwarf or one of the similar flags should > be passed to gcc instead of just -g. I'm using gcc 2.96 and > binutils version 010326 (with BFD 010326) > > Is this correct? Or that debug info is broken in the tools you are using :-). What target triple are you using for the tools? If you have a particular patch that you can verify works for you, we could try it. Note that -gdwarf wouldn't be advisable because dwarf 1 has lousy support for C++ debugging. -gdwarf-2 would be better, if that helps. > Also how is gcc v3.0 working out? I haven't reached any mips tools yet. I'm still testing the x86 due to some internal difficulties. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-08-03 13:45 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-02 22:09 [ECOS] please help me A Shobhan 2001-08-03 5:31 ` Jonathan Larmour 2001-08-03 12:27 ` A Shobhan 2001-08-03 12:41 ` Jonathan Larmour 2001-08-03 13:36 ` [ECOS] mips_rm7000.ld and dwarf Chris Morrow 2001-08-03 13:45 ` Jonathan Larmour
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).