headers
Chris Johns | 1 Jun 2005 03:17
Favicon

Re: Stack filling.

Joel Sherrill <joel@...> wrote:
> Till Straumann wrote:
> 
>> Will the stack filling be optional? There might be concerns about 
>> performance
>> suffering, especially on slower CPUs.
> 
> 
> This is my concern also.  I do not want it in the code base for
> thread creation by default either.

Agreed.

> It would be OK to have a
> shared support routine in score to fill a thread stack

Ok.

> but it
> should be turned on/referenced by either a capture engine
> extension or the stack check extension.
> 

The capture engine is designed to be installed at runtime. This means 
the configuration change is not made until after RTEMS is running so 
some tasks missing having the stack initialised.

How does the current stack checker handle this ?

Could we make this an RTEMS debug flag ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
leonp | 1 Jun 2005 09:25
Favicon

Re: How to mask IRQ

On Tuesday, 31 בMay 2005 20:34, Thomas Doerfler wrote:
> Leon,
>
> I had a look into the mbx8xx BSP irq handler code as an example. At a
> first glance I would say, that no API extension would be needed to
> achive your functionality, but the current implementation would need
> some modifications.
>
> You already have the two calls:
>
> int BSP_install_rtems_irq_handler  (const rtems_irq_connect_data* irq);
> int BSP_remove_rtems_irq_handler  (const rtems_irq_connect_data* irq);
>
> and
>
> int BSP_get_current_rtems_irq_handler	(rtems_irq_connect_data* irq);
>
> Currently, I think, it is not yet safe to call
> "BSP_remove_rtems_irq_handler" from an ISR, but I think with some
> careful tinkering it could be made safe.
>
> Would this be ok for your requirements?
Thanks Thomas.
	Well, for my current project any of these solutions will be OK :-)
	But I think that this seems to be a high price to be paid for a simple 
operation, such as masking of interrupt. These routines you mentioned are 
relatively heavy, a lot of code.
	And it requires some significant redesign, as for now it simply will not 
work: the BSP_remove_rtems_irq_handler() masks the SIU interrupt and stores 
the "new" mask in the same ppc_chached_mask variable which is restored in the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thomas Doerfler | 1 Jun 2005 14:28
Picon
Favicon

Re: How to mask IRQ

Leon,

leonp@... schrieb:
> On Tuesday, 31 בMay 2005 20:34, Thomas Doerfler wrote:
> 
>>Would this be ok for your requirements?
> 
> Thanks Thomas.
> 	Well, for my current project any of these solutions will be OK :-)
> 	But I think that this seems to be a high price to be paid for a simple 
> operation, such as masking of interrupt. These routines you mentioned are 
> relatively heavy, a lot of code.
> 	And it requires some significant redesign, as for now it simply will not 
> work: the BSP_remove_rtems_irq_handler() masks the SIU interrupt and stores 
> the "new" mask in the same ppc_chached_mask variable which is restored in the 
> handler after ISR return.
> 	Thus, any changes will be destroyed at the ISR exit.
> 
> Am I correct?

Yes, you are right, some details must be carefully modified in the
current implementation to use the API from within interrupt context. And
you are right again, the existing calls are quite expensive. Do you have
any other recommendations to solve your requirements?
wkr,
Thomas.

--

-- 
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
(Continue reading)

Permalink | Reply | 5 comments |
headers
leonp | 1 Jun 2005 14:40
Favicon

Re: How to mask IRQ

On Wednesday, 1 בJune 2005 15:28, Thomas Doerfler wrote:
> Yes, you are right, some details must be carefully modified in the
> current implementation to use the API from within interrupt context. And
> you are right again, the existing calls are quite expensive. Do you have
> any other recommendations to solve your requirements?
I also do not like the "returned value" solution , although I suggested it.
The API functions are much more elegant.

But in the current time constrains I have, the simplest and securest thing I 
see is only this. And it adds only 2 assembler instructions overhead (to test 
the returned value).

Thanks for the help.
--

-- 
Leon M.Pollak
Permalink | Reply | 4 comments |
headers
Sergei Organov | 1 Jun 2005 14:56
Picon

Re: How to mask IRQ

leonp@... writes:

> On Wednesday, 1 в▒June 2005 15:28, Thomas Doerfler wrote:
> > Yes, you are right, some details must be carefully modified in the
> > current implementation to use the API from within interrupt context. And
> > you are right again, the existing calls are quite expensive. Do you have
> > any other recommendations to solve your requirements?
> I also do not like the "returned value" solution , although I suggested it.
> The API functions are much more elegant.
> 
> But in the current time constrains I have, the simplest and securest
> thing I see is only this. And it adds only 2 assembler instructions
> overhead (to test the returned value).

Sorry, but I fail to see how it supposed to work if your IRQ handler is
invoked when another IRQ handler is running. Your change to the
ppc_cached_irq_mask on exit from your IRQ handler will be overwritten on
return from another IRQ handler. Am I missing something?

--

-- 
Sergei.
Permalink | Reply | 3 comments |
headers
leonp | 1 Jun 2005 15:01
Favicon

Re: How to mask IRQ

On Wednesday, 1 בJune 2005 15:56, Sergei Organov wrote:
> leonp@... writes:
> > On Wednesday, 1 в▒June 2005 15:28, Thomas Doerfler wrote:
> > > Yes, you are right, some details must be carefully modified in the
> > > current implementation to use the API from within interrupt context.
> > > And you are right again, the existing calls are quite expensive. Do you
> > > have any other recommendations to solve your requirements?
> >
> > I also do not like the "returned value" solution , although I suggested
> > it. The API functions are much more elegant.
> >
> > But in the current time constrains I have, the simplest and securest
> > thing I see is only this. And it adds only 2 assembler instructions
> > overhead (to test the returned value).
>
> Sorry, but I fail to see how it supposed to work if your IRQ handler is
> invoked when another IRQ handler is running. Your change to the
> ppc_cached_irq_mask on exit from your IRQ handler will be overwritten on
> return from another IRQ handler. Am I missing something?

Yes, the thing you are missing is the fact that I am stupid...:-)

--

-- 
Leon M.Pollak
Permalink | Reply | 0 comments |
headers
eric.valette | 1 Jun 2005 15:03
Picon
Favicon

Re: How to mask IRQ

Quoting Sergei Organov <osv@...>:

> leonp@... writes:
>

> Sorry, but I fail to see how it supposed to work if your IRQ handler is
> invoked when another IRQ handler is running. Your change to the
> ppc_cached_irq_mask on exit from your IRQ handler will be overwritten on
> return from another IRQ handler. Am I missing something?

This is exactly why manipulating masks within one interrupt handler
leads to non working code : what mask do you intend to restore and when?.

-- eric
Permalink | Reply | 1 comment |
headers
leonp | 1 Jun 2005 15:04
Favicon

S.Organov address

Sergei,
	How can it be that each time I send something (also to you) I receive:

   ----- The following addresses had permanent fatal errors -----
<osv@...>
    (reason: 550 5.0.0 I do not accept a viruses and spam!)

   ----- Transcript of session follows -----
... while talking to ns.topconrd.ru.:
>>> MAIL From:<leonp@...>
<<< 550 5.0.0 I do not accept a viruses and spam!
554 5.0.0 Service unavailable

--

-- 
Leon M.Pollak
Permalink | Reply | 501 comments |
headers
Sergei Organov | 1 Jun 2005 15:09
Picon

Re: How to mask IRQ

eric.valette@... writes:

> Quoting Sergei Organov <osv@...>:
> 
> > leonp@... writes:
> >
> 
> > Sorry, but I fail to see how it supposed to work if your IRQ handler is
> > invoked when another IRQ handler is running. Your change to the
> > ppc_cached_irq_mask on exit from your IRQ handler will be overwritten on
> > return from another IRQ handler. Am I missing something?
> 
> This is exactly why manipulating masks within one interrupt handler
> leads to non working code : what mask do you intend to restore and
> when?.

I believe I've already posted working solution that correctly emulates
hardware PIC with ability to mask/unmask individual interrupts earlier
in this thread.

--

-- 
Sergei.
Permalink | Reply | 0 comments |
headers
Joel Sherrill | 1 Jun 2005 15:14

Re: Stack filling.

Chris Johns wrote:
> Joel Sherrill <joel@...> wrote:

> The capture engine is designed to be installed at runtime. This means 
> the configuration change is not made until after RTEMS is running so 
> some tasks missing having the stack initialised.
> 
> How does the current stack checker handle this ?

It is turned on at configure time as a static extension so it impacts
all threads that are created.

> Could we make this an RTEMS debug flag ?

This is a possibility.  I would really like to see a "debug/profile" 
alternate build version of RTEMS that turns on all the heap checking,
stack checking, mutex lock order checking, etc. It would be considerably
slower and more code space but worth it from a consistency check.

If there were a set of global debug settings, then these checks could
be in the build and turned on and off at run-time.

--joel
Permalink | Reply | 0 comments |

Gmane