[ECOS] Problems with ISR/DSR stacks

[ECOS] Problems with ISR/DSR stacks

[Øyvind Harboe]

Enabling INFRA_DEBUG crashes my "rocket"...

As far as I can tell the DSR runs run on the thread stack and not the
interrupt stack(from inside interrupt_end).

Also, as long as the interrupt handling in a HAL does not support
interrupt nesting, then there is no point in adding support for an
interrupt stack as a single level ISR probably uses less stack than a
DSR anyway.

DSR's don't nest. However, any DSR that uses a non-trivial amount of
stack is *nasty* as all threads in the system then needs to have
enough stack to accomodate that DSR. This gets even nastier as there
is no way for a DSR to enforce all threads to have this extra amount
of stack.

The thing that I don't understand is why there is no DSR stack....

DSR's can be interrupted by ISR's but not by threads, so presumably
the requirement to be on the interrupted threads stack arises *after*
the DSR's have run?

My system crashes when I enable INFRA_DEBUG because an assert is
triggered during a DSR where diag_printf() is invoked and this blows
the stack. Initially with the DHCP client in the FreeBSD tcp/ip stack
for which I submitted a patch that got accepted a  while ago, but
other thread suffer the same faith.

http://ecos.sourceware.org/docs-2.0/ref/hal-default-interrupt-handling.html

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problems with ISR/DSR stacks

[Nick Garnett]

"Øyvind Harboe" <oyvind.harboe@zylin.com> writes:

> Enabling INFRA_DEBUG crashes my "rocket"...
> 
> As far as I can tell the DSR runs run on the thread stack and not the
> interrupt stack(from inside interrupt_end).

No. DSRs run on the interrupt stack. This is what
hal_interrupt_stack_call_pending_DSRs() does.

> 
> Also, as long as the interrupt handling in a HAL does not support
> interrupt nesting, then there is no point in adding support for an
> interrupt stack as a single level ISR probably uses less stack than a
> DSR anyway.

That depends entirely on what the ISR and DSR do. If the DSR calls
diag_printf() then it may use a lot more stack. There are reasons for
having an interrupt stack other than nested interrupts, as you have
discovered.

> 
> DSR's don't nest. However, any DSR that uses a non-trivial amount of
> stack is *nasty* as all threads in the system then needs to have
> enough stack to accomodate that DSR. This gets even nastier as there
> is no way for a DSR to enforce all threads to have this extra amount
> of stack.

If you disable the interrupt stack then you have to deal with the
consequences. It is not recommended unless you know what you are
doing. 

Switching to the interrupt stack to run DSRs was introduced precisely
to avoid having to have enough space in all thread stacks to
accommodate all DSRs. 

> 
> The thing that I don't understand is why there is no DSR stack....

There is, it is the interrupt stack.

> 
> DSR's can be interrupted by ISR's but not by threads, so presumably
> the requirement to be on the interrupted threads stack arises *after*
> the DSR's have run?

interrupt_end() must be called on the thread stack since it may cause
a thread switch. 

> 
> My system crashes when I enable INFRA_DEBUG because an assert is
> triggered during a DSR where diag_printf() is invoked and this blows
> the stack. Initially with the DHCP client in the FreeBSD tcp/ip stack
> for which I submitted a patch that got accepted a  while ago, but
> other thread suffer the same faith.

This is just one of the consequences you have to deal with if you
disable the interrupt stack. Don't do it.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problems with ISR/DSR stacks

[Øyvind Harboe]

On 06 Jun 2007 10:31:37 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> "Øyvind Harboe" <oyvind.harboe@zylin.com> writes:
>
> > Enabling INFRA_DEBUG crashes my "rocket"...
> >
> > As far as I can tell the DSR runs run on the thread stack and not the
> > interrupt stack(from inside interrupt_end).
>
> No. DSRs run on the interrupt stack. This is what
> hal_interrupt_stack_call_pending_DSRs() does.

Ah. OK. I'll have to dig into that, but that does give interrupt
stacks a lot more oomph.

> If you disable the interrupt stack then you have to deal with the
> consequences. It is not recommended unless you know what you are
> doing.

I haven't added interrupt stacks to my HAL yet, but is sure is on my
list now(together with GDB support and a number of other things). :-)

Thanks for the clarification!

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problems with ISR/DSR stacks

[Nick Garnett]

"Øyvind Harboe" <oyvind.harboe@zylin.com> writes:

> On 06 Jun 2007 10:31:37 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> > "Øyvind Harboe" <oyvind.harboe@zylin.com> writes:
> >
> > > Enabling INFRA_DEBUG crashes my "rocket"...
> > >
> > > As far as I can tell the DSR runs run on the thread stack and not the
> > > interrupt stack(from inside interrupt_end).
> >
> > No. DSRs run on the interrupt stack. This is what
> > hal_interrupt_stack_call_pending_DSRs() does.
> 
> Ah. OK. I'll have to dig into that, but that does give interrupt
> stacks a lot more oomph.

The term "interrupt_stack" is a bit of a misnomer, it often gets used
for all sorts of things: it's the startup stack; interrupts of course;
running DSRs and sometimes exception handling. It depends on the HAL
and who originally wrote it -- I recommend looking at the MIPS and
PowerPC HALs for the best examples.

> 
> > If you disable the interrupt stack then you have to deal with the
> > consequences. It is not recommended unless you know what you are
> > doing.
> 
> I haven't added interrupt stacks to my HAL yet, but is sure is on my
> list now(together with GDB support and a number of other things). :-)

If you are doing a new port then the best thing to do at this stage is
to just increase the minimum thread stack size by a couple of K,
assuming you have the memory. That should allow you to get all the
rest of the HAL running before dealing with the interrupt stack
switching, which can be a bit tricky.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problems with ISR/DSR stacks

[Øyvind Harboe]

On 06 Jun 2007 11:33:36 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> "Øyvind Harboe" <oyvind.harboe@zylin.com> writes:
>
> > On 06 Jun 2007 10:31:37 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> > > "Øyvind Harboe" <oyvind.harboe@zylin.com> writes:
> > >
> > > > Enabling INFRA_DEBUG crashes my "rocket"...
> > > >
> > > > As far as I can tell the DSR runs run on the thread stack and not the
> > > > interrupt stack(from inside interrupt_end).
> > >
> > > No. DSRs run on the interrupt stack. This is what
> > > hal_interrupt_stack_call_pending_DSRs() does.
> >
> > Ah. OK. I'll have to dig into that, but that does give interrupt
> > stacks a lot more oomph.
>
> The term "interrupt_stack" is a bit of a misnomer, it often gets used
> for all sorts of things: it's the startup stack; interrupts of course;
> running DSRs and sometimes exception handling. It depends on the HAL
> and who originally wrote it -- I recommend looking at the MIPS and
> PowerPC HALs for the best examples.

Thanks for the tip!

> > > If you disable the interrupt stack then you have to deal with the
> > > consequences. It is not recommended unless you know what you are
> > > doing.
> >
> > I haven't added interrupt stacks to my HAL yet, but is sure is on my
> > list now(together with GDB support and a number of other things). :-)
>
> If you are doing a new port then the best thing to do at this stage is
> to just increase the minimum thread stack size by a couple of K,
> assuming you have the memory. That should allow you to get all the
> rest of the HAL running before dealing with the interrupt stack
> switching, which can be a bit tricky.

That's what I did to get out of jail for now, so yes, it worked.

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss