[ECOS] Linux over RedBoot

[ECOS] Linux over RedBoot

[Venkat Mynampati]

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 .

Re: [ECOS] Linux over RedBoot

[Jonathan Larmour]

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/

RE: [ECOS] Linux over RedBoot

[Gary Thomas]

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?

Re: [ECOS] Linux over RedBoot

[Fabrice Gautier]

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>

Re: [ECOS] Linux over RedBoot

[Jesper Skov]

>>>>> "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

Re: [ECOS] Linux over RedBoot

[Gary Thomas]

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'.

Re: [ECOS] Linux over RedBoot

[Fabrice Gautier]

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>

Re: [ECOS] Linux over RedBoot

[Gary Thomas]

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.

Re: [ECOS] Linux over RedBoot

[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

[ECOS] sscanf() vs. fgetc()

[Peter Graf]

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;
}

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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]

Re: [ECOS] sscanf() vs. fgetc()

[Robin Farine]

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

Re: [ECOS] sscanf() vs. fgetc()

[Jonathan Larmour]

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/

Re: [ECOS] sscanf() vs. fgetc()

[Robin Farine]

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 ;-))

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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

Re: [ECOS] sscanf() vs. fgetc()

[Jonathan Larmour]

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/

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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

Re: [ECOS] sscanf() vs. fgetc()

[Jonathan Larmour]

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/

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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

Re: [ECOS] sscanf() vs. fgetc()

[Robin Farine]

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

Re: [ECOS] sscanf() vs. fgetc()

[Jonathan Larmour]

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/

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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

Re: [ECOS] sscanf() vs. fgetc()

[Peter Graf]

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