* [ECOS] Linux over RedBoot @ 2001-07-11 14:09 Venkat Mynampati 2001-07-11 14:36 ` Jonathan Larmour ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Venkat Mynampati @ 2001-07-11 14:09 UTC (permalink / raw) To: ecos-discuss Hi, Has anyone tried running Linux over Redboot? i.e a configuration in which redboot is running in flash and linux is loaded into Ram/flash. Could you pls letme know if you were successful in this and how you did it. Thanks and Regards Venkat N _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com . ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-11 14:09 [ECOS] Linux over RedBoot Venkat Mynampati @ 2001-07-11 14:36 ` Jonathan Larmour 2001-07-11 14:53 ` Gary Thomas 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf 2 siblings, 0 replies; 23+ messages in thread From: Jonathan Larmour @ 2001-07-11 14:36 UTC (permalink / raw) To: Venkat Mynampati; +Cc: ecos-discuss Venkat Mynampati wrote: > > Hi, > Has anyone tried running Linux over Redboot? Yes. Lots. > i.e a configuration in which redboot is running > in flash and linux is loaded into Ram/flash. > > Could you pls letme know if you were successful > in this and how you did it. We have a demo on the iPaq for example: http://sources.redhat.com/redboot/ipaq/ 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 Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [ECOS] Linux over RedBoot 2001-07-11 14:09 [ECOS] Linux over RedBoot Venkat Mynampati 2001-07-11 14:36 ` Jonathan Larmour @ 2001-07-11 14:53 ` Gary Thomas 2001-07-11 20:32 ` Fabrice Gautier 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf 2 siblings, 1 reply; 23+ messages in thread From: Gary Thomas @ 2001-07-11 14:53 UTC (permalink / raw) To: Venkat Mynampati; +Cc: ecos-discuss On 11-Jul-2001 Venkat Mynampati wrote: > Hi, > Has anyone tried running Linux over Redboot? > i.e a configuration in which redboot is running > in flash and linux is loaded into Ram/flash. > > Could you pls letme know if you were successful > in this and how you did it. We do it all the time on a number of different platforms. Do you have specific questions about this, or just wondering? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-11 14:53 ` Gary Thomas @ 2001-07-11 20:32 ` Fabrice Gautier 2001-07-11 23:37 ` Jesper Skov 0 siblings, 1 reply; 23+ messages in thread From: Fabrice Gautier @ 2001-07-11 20:32 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss On Wed, 11 Jul 2001 15:53:14 -0600 (MDT) Gary Thomas <gthomas@redhat.com> wrote: > > On 11-Jul-2001 Venkat Mynampati wrote: > > Has anyone tried running Linux over Redboot? > > We do it all the time on a number of different platforms. > > Do you have specific questions about this, or just wondering? Yes, one (for now) Does your linux kernel use Redboots Virtual Vectors and stuff or is Redboot just wiped from memory once the kernel is launched? Thanks -- Fabrice Gautier <gautier@email.enstfr> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-11 20:32 ` Fabrice Gautier @ 2001-07-11 23:37 ` Jesper Skov 2001-07-12 5:11 ` Gary Thomas 0 siblings, 1 reply; 23+ messages in thread From: Jesper Skov @ 2001-07-11 23:37 UTC (permalink / raw) To: Fabrice Gautier; +Cc: Gary Thomas, ecos-discuss >>>>> "Fabrice" == Fabrice Gautier <gautier@email.enst.fr> writes: Fabrice> On Wed, 11 Jul 2001 15:53:14 -0600 (MDT) Fabrice> Gary Thomas <gthomas@redhat.com> wrote: >> >> On 11-Jul-2001 Venkat Mynampati wrote: >> > Has anyone tried running Linux over Redboot? >> >> We do it all the time on a number of different platforms. >> >> Do you have specific questions about this, or just wondering? Fabrice> Yes, one (for now) Does your linux kernel use Redboots Fabrice> Virtual Vectors and stuff or is Redboot just wiped from Fabrice> memory once the kernel is launched? RedBoot is wiped on all platforms. Linux runs directly on the hardware. However, on SH platforms RedBoot can still be used to debug the Linux kernel (via serial only though). Jesper ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-11 23:37 ` Jesper Skov @ 2001-07-12 5:11 ` Gary Thomas 2001-07-12 5:30 ` Fabrice Gautier 0 siblings, 1 reply; 23+ messages in thread From: Gary Thomas @ 2001-07-12 5:11 UTC (permalink / raw) To: Jesper Skov; +Cc: ecos-discuss, Fabrice Gautier On 12-Jul-2001 Jesper Skov wrote: >>>>>> "Fabrice" == Fabrice Gautier <gautier@email.enst.fr> writes: > > Fabrice> On Wed, 11 Jul 2001 15:53:14 -0600 (MDT) > Fabrice> Gary Thomas <gthomas@redhat.com> wrote: >>> >>> On 11-Jul-2001 Venkat Mynampati wrote: >>> > Has anyone tried running Linux over Redboot? >>> >>> We do it all the time on a number of different platforms. >>> >>> Do you have specific questions about this, or just wondering? > > Fabrice> Yes, one (for now) Does your linux kernel use Redboots > Fabrice> Virtual Vectors and stuff or is Redboot just wiped from > Fabrice> memory once the kernel is launched? > > RedBoot is wiped on all platforms. Linux runs directly on the > hardware. > > However, on SH platforms RedBoot can still be used to debug the Linux > kernel (via serial only though). This is purely a matter of *cooperation* - if the Linux kernel is willing to cooperate with the debug agent [RedBoot], as with the SH version, then many things are possible. In most cases, Linux considers itself omnipotent and RedBoot is out of the picture the instant you say 'exec'. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-12 5:11 ` Gary Thomas @ 2001-07-12 5:30 ` Fabrice Gautier 2001-07-12 5:39 ` Gary Thomas 0 siblings, 1 reply; 23+ messages in thread From: Fabrice Gautier @ 2001-07-12 5:30 UTC (permalink / raw) To: Gary Thomas; +Cc: Jesper Skov, ecos-discuss On Thu, 12 Jul 2001 06:11:03 -0600 (MDT) Gary Thomas <gthomas@redhat.com> wrote: > > On 12-Jul-2001 Jesper Skov wrote: > >>>>>> "Fabrice" == Fabrice Gautier <gautier@email.enst.fr> writes: > > > > Fabrice> Yes, one (for now) Does your linux kernel use Redboots > > Fabrice> Virtual Vectors and stuff or is Redboot just wiped from > > Fabrice> memory once the kernel is launched? > > > > RedBoot is wiped on all platforms. Linux runs directly on the > > hardware. > > > > However, on SH platforms RedBoot can still be used to debug the Linux > > kernel (via serial only though). > > This is purely a matter of *cooperation* - if the Linux kernel is willing > to cooperate with the debug agent [RedBoot], as with the SH version, then > many things are possible. In most cases, Linux considers itself omnipotent > and RedBoot is out of the picture the instant you say 'exec'. How come that the SH port of the linux kernel is cooperating with Redboot? Is it because the ones who initiated the SH port of the linux kernel had choosen redboot as their boot loader? Or has this been added afterward? Do you have any ideas of how dificult it would be to have this same cooperation for other linux kernel ports, eg i386 or arm ? -- Fabrice Gautier <gautier@email.enstfr> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-12 5:30 ` Fabrice Gautier @ 2001-07-12 5:39 ` Gary Thomas 2001-07-12 5:45 ` Jesper Skov 0 siblings, 1 reply; 23+ messages in thread From: Gary Thomas @ 2001-07-12 5:39 UTC (permalink / raw) To: Fabrice Gautier; +Cc: ecos-discuss, Jesper Skov On 12-Jul-2001 Fabrice Gautier wrote: > > On Thu, 12 Jul 2001 06:11:03 -0600 (MDT) > Gary Thomas <gthomas@redhat.com> wrote: > >> >> On 12-Jul-2001 Jesper Skov wrote: >> >>>>>> "Fabrice" == Fabrice Gautier <gautier@email.enst.fr> writes: >> > >> > Fabrice> Yes, one (for now) Does your linux kernel use Redboots >> > Fabrice> Virtual Vectors and stuff or is Redboot just wiped from >> > Fabrice> memory once the kernel is launched? >> > >> > RedBoot is wiped on all platforms. Linux runs directly on the >> > hardware. >> > >> > However, on SH platforms RedBoot can still be used to debug the Linux >> > kernel (via serial only though). >> >> This is purely a matter of *cooperation* - if the Linux kernel is willing >> to cooperate with the debug agent [RedBoot], as with the SH version, then >> many things are possible. In most cases, Linux considers itself omnipotent >> and RedBoot is out of the picture the instant you say 'exec'. > > How come that the SH port of the linux kernel is cooperating with > Redboot? Is it because the ones who initiated the SH port of the linux > kernel had choosen redboot as their boot loader? Or has this been added > afterward? Hard to say, but the fact that Red Hat has done a lot of work on the Linux/SH port early on probably helped. > > Do you have any ideas of how dificult it would be to have this same > cooperation for other linux kernel ports, eg i386 or arm ? > I don't know about the x86, but for the ARM it's not that big a deal, probably measured in man days instead of weeks or months. The real problem with such efforts is not to make them available but rather to get them accepted into the mainline Linux sources. Note: we (Red Hat) wouldn't have the time or resources to do this for any particular platform unless that effort was driven by a customer contract. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] Linux over RedBoot 2001-07-12 5:39 ` Gary Thomas @ 2001-07-12 5:45 ` Jesper Skov 0 siblings, 0 replies; 23+ messages in thread From: Jesper Skov @ 2001-07-12 5:45 UTC (permalink / raw) To: Gary Thomas; +Cc: Fabrice Gautier, ecos-discuss, Jesper Skov >>>>> "Gary" == Gary Thomas <gthomas@redhat.com> writes: >> How come that the SH port of the linux kernel is cooperating with >> Redboot? Is it because the ones who initiated the SH port of the >> linux kernel had choosen redboot as their boot loader? Or has this >> been added afterward? Gary> Hard to say, but the fact that Red Hat has done a lot of work on Gary> the Linux/SH port early on probably helped. FAOD the other SH boot loaders already provided that feature and Linux/SH was ready for it. So it was really RedBoot that adopted an already existing (very nice) feature. Jesper ^ permalink raw reply [flat|nested] 23+ messages in thread
* [ECOS] sscanf() vs. fgetc() 2001-07-11 14:09 [ECOS] Linux over RedBoot Venkat Mynampati 2001-07-11 14:36 ` Jonathan Larmour 2001-07-11 14:53 ` Gary Thomas @ 2001-07-12 1:54 ` Peter Graf 2001-07-12 3:23 ` Peter Graf ` (2 more replies) 2 siblings, 3 replies; 23+ messages in thread From: Peter Graf @ 2001-07-12 1:54 UTC (permalink / raw) To: ecos-discuss Hi, after problems in a large context, I have cut things down to a short example for a phenomenon I can't explain myself. I create and resume a new thread which uses fgetc() on a serial port, in an infinite loop. This new thread has a higher priority than the old one. If no characters are received, fgetc blocks and the old thread continues. So far so good. But when I use sscanf() in the old thread, it hangs. Even if the new process completes fgetc(), because characters are received, the old process won't get any further. My first explanation was, that fgetc() might poll and doesn't allow to schedule lower priority threads. Obviously, this was wrong, because the old thread runs fine, as long as it doesn't use sscanf(), even if it calls C Library functions like sprintf(). My second explanation was that there might be a resource conflict between fgetc() and sscanf(). (I have no idea why there should be such a conflict!) So I placed a scheduler lock around sscanf(). It still hangs. (And the higher priority task as well.) I found two ways to keep sscanf() from hanging, which is giving the fgetc() thread a lower priority, or add a cyg_thread_delay() after the fgetc(). It is not that I could not work around this phenomenon, but I am concerned of unexpected conflicts between C Library functions running in different tasks. So I would be happy if someone can enlighten me... (Assertions give no clue. Target is Hitachi SH3.) Peter Code to reproduce this: ---------------------------------------------------------------------------- -------- #include <cyg/kernel/kapi.h> #include <cyg/infra/diag.h> #include <stdio.h> #include <string.h> FILE* serin; FILE* serout; /* This thread uses fgetc() */ void trans_serial( cyg_addrword_t setup_data ) { char ch; while (1) { diag_printf("fgetc()...\n\r"); ch = fgetc(serin); diag_printf("fgetc() done.\n\r"); // cyg_thread_delay(10); } } cyg_thread SerInputProc; cyg_handle_t SerInputProcHandle; unsigned int SerInput_WSP[2048]; #define SER_INPUT_PRIO 9 int main(void) { char theIPAddressPtr[16] = "128.128.128.121"; int theIP[4]; volatile int i; serin = fopen("/dev/ser2","r"); serout = fopen("/dev/ser2","w"); fprintf(serout,"Hallo\n\r"); diag_printf("cyg_thread_create()...\n\r"); cyg_thread_create( SER_INPUT_PRIO, trans_serial, (cyg_addrword_t) 0, "SerialInputProcess", (void*) SerInput_WSP, 2048, &SerInputProcHandle, &SerInputProc ); diag_printf("cyg_thread_resume...\n\r"); cyg_thread_resume( SerInputProcHandle ); diag_printf("loop...\n\r"); for (i=0; i++; i<1000); diag_printf("sprintf...\n\r"); sprintf( theIPAddressPtr, "128.128.128.122" ); // cyg_scheduler_lock(); diag_printf("sscanf...\n\r"); sscanf( theIPAddressPtr, "%d.%d.%d.%d", &theIP[0], &theIP[1], &theIP[2], &theIP[3] ); diag_printf("sscanf done.\n\r"); // cyg_scheduler_unlock(); diag_printf("loop...\n\r"); for (i=0; i++; i<1000); diag_printf("main() finished\n\r"); while (1) cyg_thread_delay(100); return 0; } ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf @ 2001-07-12 3:23 ` Peter Graf 2001-07-12 3:28 ` Robin Farine 2001-07-12 4:00 ` Jonathan Larmour 2 siblings, 0 replies; 23+ messages in thread From: Peter Graf @ 2001-07-12 3:23 UTC (permalink / raw) To: ecos-discuss Jonathan Larmour wrote: >Is the fileio package enabled in your configuration? Yes. Peter >> after problems in a large context, I have cut things down to a short >> example for a phenomenon I can't explain myself. >> >> I create and resume a new thread which uses fgetc() on a serial port, in an >> infinite loop. >> This new thread has a higher priority than the old one. >> If no characters are received, fgetc blocks and the old thread continues. >> >> So far so good. >> >> But when I use sscanf() in the old thread, it hangs. >> Even if the new process completes fgetc(), because characters are received, >> the old process won't get any further. >> >> My first explanation was, that fgetc() might poll and doesn't allow to >> schedule lower priority threads. Obviously, this was wrong, because the old >> thread runs fine, as long as it doesn't use sscanf(), even if it calls C >> Library functions like sprintf(). >> >> My second explanation was that there might be a resource conflict between >> fgetc() and sscanf(). (I have no idea why there should be such a conflict!) >> So I placed a scheduler lock around sscanf(). It still hangs. (And the >> higher priority task as well.) >> >> I found two ways to keep sscanf() from hanging, which is giving the fgetc() >> thread a lower priority, or add a cyg_thread_delay() after the fgetc(). >> >> It is not that I could not work around this phenomenon, but I am concerned >> of unexpected conflicts between C Library functions running in different >> tasks. So I would be happy if someone can enlighten me... >> >> (Assertions give no clue. Target is Hitachi SH3.) >> >> [snip] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf 2001-07-12 3:23 ` Peter Graf @ 2001-07-12 3:28 ` Robin Farine 2001-07-12 3:42 ` Jonathan Larmour 2001-07-12 3:45 ` Peter Graf 2001-07-12 4:00 ` Jonathan Larmour 2 siblings, 2 replies; 23+ messages in thread From: Robin Farine @ 2001-07-12 3:28 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss Hi Peter, Peter Graf <p.graf@itknet.de> writes: > Hi, > > after problems in a large context, I have cut things down to a short > example for a phenomenon I can't explain myself. > > I create and resume a new thread which uses fgetc() on a serial port, in an > infinite loop. > This new thread has a higher priority than the old one. > If no characters are received, fgetc blocks and the old thread continues. > > So far so good. > > But when I use sscanf() in the old thread, it hangs. > Even if the new process completes fgetc(), because characters are received, > the old process won't get any further. I suppose that only one thread at a time can read characters from a serial port. When a thread wants to read, it probably has to obtain a mutex, then it checks a condition such as input buffer not empty or waits on a condition variable bound to this condition. When some characters come in, the condition variable gets signalled and the thread with the higher priority runs and consumes the available characters. Therefore, another thread with a lower priority will never get a chance to see a non-empty buffer, or in one word: starvation. > My first explanation was, that fgetc() might poll and doesn't allow to > schedule lower priority threads. Obviously, this was wrong, because the old > thread runs fine, as long as it doesn't use sscanf(), even if it calls C > Library functions like sprintf(). > > My second explanation was that there might be a resource conflict between > fgetc() and sscanf(). (I have no idea why there should be such a conflict!) > So I placed a scheduler lock around sscanf(). It still hangs. (And the > higher priority task as well.) > > I found two ways to keep sscanf() from hanging, which is giving the fgetc() > thread a lower priority, or add a cyg_thread_delay() after the fgetc(). This confirms the hypothesis above. Robin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 3:28 ` Robin Farine @ 2001-07-12 3:42 ` Jonathan Larmour 2001-07-12 5:02 ` Robin Farine 2001-07-12 3:45 ` Peter Graf 1 sibling, 1 reply; 23+ messages in thread From: Jonathan Larmour @ 2001-07-12 3:42 UTC (permalink / raw) To: Robin Farine; +Cc: Peter Graf, ecos-discuss Robin Farine wrote: > > Hi Peter, > > Peter Graf <p.graf@itknet.de> writes: > > > Hi, > > > > after problems in a large context, I have cut things down to a short > > example for a phenomenon I can't explain myself. > > > > I create and resume a new thread which uses fgetc() on a serial port, in an > > infinite loop. > > This new thread has a higher priority than the old one. > > If no characters are received, fgetc blocks and the old thread continues. > > > > So far so good. > > > > But when I use sscanf() in the old thread, it hangs. > > Even if the new process completes fgetc(), because characters are received, > > the old process won't get any further. > > I suppose that only one thread at a time can read characters from a serial > port. Yes, but *s*scanf() isn't reading from the serial port. 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 Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 3:42 ` Jonathan Larmour @ 2001-07-12 5:02 ` Robin Farine 0 siblings, 0 replies; 23+ messages in thread From: Robin Farine @ 2001-07-12 5:02 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Robin Farine, ecos-discuss Jonathan Larmour <jlarmour@redhat.com> writes: > Yes, but *s*scanf() isn't reading from the serial port. Ah, so stupid, I thought *s* standed for *s*erial ;-)) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 3:28 ` Robin Farine 2001-07-12 3:42 ` Jonathan Larmour @ 2001-07-12 3:45 ` Peter Graf 1 sibling, 0 replies; 23+ messages in thread From: Peter Graf @ 2001-07-12 3:45 UTC (permalink / raw) To: ecos-discuss Hi Robin, >> But when I use sscanf() in the old thread, it hangs. >> Even if the new process completes fgetc(), because characters are received, >> the old process won't get any further. > >I suppose that only one thread at a time can read characters from a serial >port. When a thread wants to read, it probably has to obtain a mutex, then it >checks a condition such as input buffer not empty or waits on a condition >variable bound to this condition. When some characters come in, the condition >variable gets signalled and the thread with the higher priority runs and >consumes the available characters. Therefore, another thread with a lower >priority will never get a chance to see a non-empty buffer, or in one word: >starvation. You are obviously right, but: My sscanf() does access a *string*, which is absolutely not related to the *serial port* read by fgetc(). Peter ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf 2001-07-12 3:23 ` Peter Graf 2001-07-12 3:28 ` Robin Farine @ 2001-07-12 4:00 ` Jonathan Larmour 2001-07-12 5:57 ` Peter Graf 2 siblings, 1 reply; 23+ messages in thread From: Jonathan Larmour @ 2001-07-12 4:00 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss Peter Graf wrote: > > Hi, > > after problems in a large context, I have cut things down to a short > example for a phenomenon I can't explain myself. > > I create and resume a new thread which uses fgetc() on a serial port, in an > infinite loop. > This new thread has a higher priority than the old one. > If no characters are received, fgetc blocks and the old thread continues. > > So far so good. > > But when I use sscanf() in the old thread, it hangs. Hmm.... cyg_thread_create()... cyg_thread_resume... fgetc()... fgetc() done. fgetc()... loop... sprintf... sscanf... sscanf done. loop... main() finished This was on a PC target FWIW. Perhaps you should step into sscanf() and see where it stops. Or if it gets stuck, press Ctrl-C and then "info threads", then switch to the main thread and do a backtrace. 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 Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 4:00 ` Jonathan Larmour @ 2001-07-12 5:57 ` Peter Graf 2001-07-12 6:13 ` Jonathan Larmour 0 siblings, 1 reply; 23+ messages in thread From: Peter Graf @ 2001-07-12 5:57 UTC (permalink / raw) To: ecos-discuss Hi Jonathan, thank you very much for trying the example. Indeeed very kind of you! >Hmm.... > >cyg_thread_create()... >cyg_thread_resume... >fgetc()... >fgetc() done. Why doesn't fgetc() block in your case? Were there characters in the serial buffer? For me, fgetc() does block due to empty buffer. >fgetc()... >loop... >sprintf... >sscanf... >sscanf done. >loop... >main() finished > >This was on a PC target FWIW. Which priority value did you have for the sscanf() thread? I had the default of "10", which means lower priority than the "9" in the fgetc() thread. (Otherwise sscanf() works for me as well.) >Perhaps you should step into sscanf() and see where it stops. I tried, of course. Singlestepping has the tendency of being a bit problematic on my target. (probably due to optimized code, and the way singlestepping works without hardware support). I experience sigtraps when trying to singlestep my way down. Ignoring them, I end up in the scheduler, but don't understand too much of what is going on there. (Not sure if I can get any meaningful results this way.) >Or if it gets stuck, press Ctrl-C and then "info threads", then switch to the main thread >and do a backtrace. Ctrl+C doesn't work for my Hitachi SH3 target. I help myself with an NMI button, so I can see memory contents, but have no easy way to get back into the main() context. Peter ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 5:57 ` Peter Graf @ 2001-07-12 6:13 ` Jonathan Larmour 2001-07-12 7:43 ` Peter Graf 0 siblings, 1 reply; 23+ messages in thread From: Jonathan Larmour @ 2001-07-12 6:13 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss Peter Graf wrote: > > Hi Jonathan, > > thank you very much for trying the example. Indeeed very kind of you! > > >Hmm.... > > > >cyg_thread_create()... > >cyg_thread_resume... > >fgetc()... > >fgetc() done. > > Why doesn't fgetc() block in your case? > Were there characters in the serial buffer? Shouldn't have been... but it may have been a glitch. > For me, fgetc() does block due to empty buffer. > > >fgetc()... It does block here though. > >loop... > >sprintf... > >sscanf... > >sscanf done. > >loop... > >main() finished > > > >This was on a PC target FWIW. > > Which priority value did you have for the sscanf() thread? > I had the default of "10", which means lower priority than > the "9" in the fgetc() thread. I used exactly your code, the only change being the serial port name (because it has to be for the PC). > >Perhaps you should step into sscanf() and see where it stops. > > I tried, of course. Singlestepping has the tendency of being a bit > problematic on my target. > (probably due to optimized code, and the way singlestepping works without > hardware support). Try recompiling eCos without optimization, i.e. editting CYGBLD_GLOBAL_CFLAGS and doing a "make clean" and then a rebuild. > I experience sigtraps when trying to singlestep my way down. Ignoring them, > I end up > in the scheduler, but don't understand too much of what is going on there. Once you've compiled without optimization hopefully that will avoid the SIGTRAPs. Can you then at least give a summary of what functions you enter as you single step? Or cut and paste a step session? 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 Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 6:13 ` Jonathan Larmour @ 2001-07-12 7:43 ` Peter Graf 2001-07-12 11:17 ` Robin Farine 0 siblings, 1 reply; 23+ messages in thread From: Peter Graf @ 2001-07-12 7:43 UTC (permalink / raw) To: ecos-discuss Hi Jonathan, >> Which priority value did you have for the sscanf() thread? >> I had the default of "10", which means lower priority than >> the "9" in the fgetc() thread. > >I used exactly your code, the only change being the serial port name >(because it has to be for the PC). Just asked because I didn't exeplicitely set the main() priority. You might have a different default. >Try recompiling eCos without optimization, i.e. editting >CYGBLD_GLOBAL_CFLAGS and doing a "make clean" and then a rebuild. Yes, I did. >Once you've compiled without optimization hopefully that will avoid the >SIGTRAPs. >Can you then at least give a summary of what functions you enter >as you single step? Or cut and paste a step session? sscanf (s=0x811472c "\b\021GL\b\021GP128.128.128.122", format=0x70707070 ...) vsscanf (s=0x8008690 ...) __strlen (s=0x202000d "") cyg_check_data_ptr (ptr=0x202000a) cyg_check_data_ptr (ptr=0x810df38) Cyg_Scheduler::unlock_inner (new_lock=0) Cyg_Thread::check_this (this=0x400001f0, zeal=134416118) Cyg_Scheduler::unlock_inner (new_lock=0) Cyg_HardwareThread::check_stack (this=0x0) Cyg_HardwareThread::get_stack_base (this=0x8084220) Cyg_HardwareThread::check_stack (this=0x810df38) Cyg_Scheduler::unlock_inner (new_lock=0) Cyg_Scheduler::unlock_inner (new_lock=0) cyg_check_data_ptr (ptr=0x803075a) Cyg_Scheduler::unlock_inner (new_lock=0) Cyg_Thread::check_this (this=0x40000100, zeal=134416294) Program received signal SIGTRAP, Trace/breakpoint trap. Do you have an idea which common resources sscanf() and fgetc() might share? Peter ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 7:43 ` Peter Graf @ 2001-07-12 11:17 ` Robin Farine 2001-07-12 11:55 ` Jonathan Larmour 2001-07-13 2:33 ` Peter Graf 0 siblings, 2 replies; 23+ messages in thread From: Robin Farine @ 2001-07-12 11:17 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss Hi Peter, I have tried your program on my SA-1110 based target. I had to add a delay in the first for loop (and fix both of them ;-)) so that the reader thread calls fgetc() before the main thread calls sscanf(). It fails on my target as well. However, there exists a link between fgetc() and sscanf() due to the implementation of sscanf(). sscanf() uses a Cyg_StdioStream() that tries to flush all the other streams at the beginning of its refill_read_buffer() operation. In my case, this seems to cause the main thread to loop endlessly in cyg_libc_stdio_flush_all_but() because stream->trylock_me() always fails. The problem comes from the conjunction of Cyg_StdioStream::refill_read_buffer() and cyg_libc_stdio_flush_all_but(). The former routine locks '*this' and calls cyg_stdio_read() which finally blocks on a condition variable, waiting for characters coming from the underlying device. Then, another thread with a higher priority (lower value) calls sscanf() => cyg_libc_stdio_flush_all_but() which spins trying to flush the other (locked) stream and thus does not give the CPU back to the lower priority thread in order to unlock the stream (provided the stream has some characters to consume). Not a very clear picture but I hope it will help more than my first message on this subject. Robin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 11:17 ` Robin Farine @ 2001-07-12 11:55 ` Jonathan Larmour 2001-07-13 2:33 ` Peter Graf 2001-07-13 2:33 ` Peter Graf 1 sibling, 1 reply; 23+ messages in thread From: Jonathan Larmour @ 2001-07-12 11:55 UTC (permalink / raw) To: Robin Farine; +Cc: Peter Graf, ecos-discuss Robin Farine wrote: > > The problem comes from the conjunction of Cyg_StdioStream::refill_read_buffer() > and cyg_libc_stdio_flush_all_but(). The former routine locks '*this' and calls > cyg_stdio_read() which finally blocks on a condition variable, waiting for > characters coming from the underlying device. Then, another thread with a higher > priority (lower value) calls sscanf() => cyg_libc_stdio_flush_all_but() which > spins trying to flush the other (locked) stream and thus does not give the CPU > back to the lower priority thread in order to unlock the stream (provided the > stream has some characters to consume). Hah. I'd just debugged this myself this far. You are entirely correct. It shouldn't wait at all for a device that's currently reading - nothing needs to be flushed. So..... Index: include/stream.hxx =================================================================== RCS file: /home/cvs/ecc/ecc/language/c/libc/stdio/current/include/stream.hxx,v retrieving revision 1.4 diff -u -5 -p -r1.4 stream.hxx --- include/stream.hxx 2001/03/16 09:04:43 1.4 +++ include/stream.hxx 2001/07/12 18:54:31 @@ -62,13 +62,19 @@ #include <cyg/kernel/mutex.hxx> // Cyg_Mutex #endif // TYPE DEFINITIONS +class Cyg_StdioStream; +__externC Cyg_ErrNo +cyg_libc_stdio_flush_all_but( Cyg_StdioStream * ); + class Cyg_StdioStream { friend int setvbuf( FILE *, char *, int, size_t ); + friend Cyg_ErrNo + cyg_libc_stdio_flush_all_but( Cyg_StdioStream * ); private: // error status for this file Cyg_ErrNo error; Index: src/common/fflush.cxx =================================================================== RCS file: /home/cvs/ecc/ecc/language/c/libc/stdio/current/src/common/fflush.cxx,v retrieving revision 1.2 diff -u -5 -p -r1.2 fflush.cxx --- src/common/fflush.cxx 2000/07/25 14:54:38 1.2 +++ src/common/fflush.cxx 2001/07/12 18:54:31 @@ -84,18 +84,20 @@ cyg_libc_stdio_flush_all_but( Cyg_StdioS files_flushed[i] = true; } // if else { // valid stream - - if ( stream->trylock_me() ) { - err = stream->flush_output_unlocked(); - stream->unlock_me(); - files_flushed[i] = true; - } // if - else - loop_again = true; + // only buffers which we've written to need flushing + if ( !stream->flags.last_buffer_op_was_read) { + if ( stream->trylock_me() ) { + err = stream->flush_output_unlocked(); + stream->unlock_me(); + files_flushed[i] = true; + } // if + else + loop_again = true; + } } // else } // if } // for } // do while(loop_again && !err); 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 Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 11:55 ` Jonathan Larmour @ 2001-07-13 2:33 ` Peter Graf 0 siblings, 0 replies; 23+ messages in thread From: Peter Graf @ 2001-07-13 2:33 UTC (permalink / raw) To: ecos-discuss; +Cc: ecos-discuss Hi Jonathan, >Hah. I'd just debugged this myself this far. Oh you could reproduce it? At first, it seemed to work on your target. >You are entirely correct. It shouldn't wait at all for a device that's >currently reading - nothing needs >to be flushed. So..... > >[snip] That I call quick response :-))) ! I've applied your patch and now everything seems to works fine! A good improvement for the eCos C Library! Thank you and Robin very much for all your help. Peter ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] sscanf() vs. fgetc() 2001-07-12 11:17 ` Robin Farine 2001-07-12 11:55 ` Jonathan Larmour @ 2001-07-13 2:33 ` Peter Graf 1 sibling, 0 replies; 23+ messages in thread From: Peter Graf @ 2001-07-13 2:33 UTC (permalink / raw) To: ecos-discuss Hi Robin, >I have tried your program on my SA-1110 based target. I had to add a delay in >the first for loop (and fix both of them ;-)) so that the reader thread calls >fgetc() before the main thread calls sscanf(). Oh, interesting. So cyg_thread_resume() doesn't cause re-scheduling immediately. I wasn't sure about this. One more thing I have learned about eCos :-) Thanks. >It fails on my target as well. Good to know. It worked for Jonathan, so I feared something target-specific. >However, there exists a link between fgetc() and sscanf() due to the >implementation of sscanf(). sscanf() uses a Cyg_StdioStream() that tries to >flush all the other streams at the beginning of its refill_read_buffer() >operation. In my case, this seems to cause the main thread to loop endlessly in >cyg_libc_stdio_flush_all_but() because stream->trylock_me() always fails. Thank you very much! I didn't get this far due to my debugging problems. >The problem comes from the conjunction of Cyg_StdioStream::refill_read_buffer() >and cyg_libc_stdio_flush_all_but(). The former routine locks '*this' and calls >cyg_stdio_read() which finally blocks on a condition variable, waiting for >characters coming from the underlying device. Then, another thread with a higher >priority (lower value) calls sscanf() => cyg_libc_stdio_flush_all_but() which >spins trying to flush the other (locked) stream and thus does not give the CPU >back to the lower priority thread in order to unlock the stream (provided the >stream has some characters to consume). > >Not a very clear picture but I hope it will help more than my first message on >this subject. It has helped a lot. Thanks you very much ! It is good to have the reasons why. I am not sure if I can fix this myself properly, but at least I know what to be aware of. Maybe, if Jonathan considers this a bug, he will help ;-) Peter ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2001-07-13 2:33 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-11 14:09 [ECOS] Linux over RedBoot Venkat Mynampati 2001-07-11 14:36 ` Jonathan Larmour 2001-07-11 14:53 ` Gary Thomas 2001-07-11 20:32 ` Fabrice Gautier 2001-07-11 23:37 ` Jesper Skov 2001-07-12 5:11 ` Gary Thomas 2001-07-12 5:30 ` Fabrice Gautier 2001-07-12 5:39 ` Gary Thomas 2001-07-12 5:45 ` Jesper Skov 2001-07-12 1:54 ` [ECOS] sscanf() vs. fgetc() Peter Graf 2001-07-12 3:23 ` Peter Graf 2001-07-12 3:28 ` Robin Farine 2001-07-12 3:42 ` Jonathan Larmour 2001-07-12 5:02 ` Robin Farine 2001-07-12 3:45 ` Peter Graf 2001-07-12 4:00 ` Jonathan Larmour 2001-07-12 5:57 ` Peter Graf 2001-07-12 6:13 ` Jonathan Larmour 2001-07-12 7:43 ` Peter Graf 2001-07-12 11:17 ` Robin Farine 2001-07-12 11:55 ` Jonathan Larmour 2001-07-13 2:33 ` Peter Graf 2001-07-13 2:33 ` Peter Graf
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).