public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@ecoscentric.com>
To: "Øyvind Harboe" <oyvind.harboe@zylin.com>
Cc: "eCos Discussion" <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Problems with ISR/DSR stacks
Date: Wed, 06 Jun 2007 09:51:00 -0000	[thread overview]
Message-ID: <m3bqfth1ja.fsf@xl5.calivar.com> (raw)
In-Reply-To: <c09652430706060150sadf4ae6m53155ca00cb95b48@mail.gmail.com>

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

  reply	other threads:[~2007-06-06  9:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06  9:36 Øyvind Harboe
2007-06-06  9:51 ` Nick Garnett [this message]
2007-06-06 10:26   ` Øyvind Harboe
2007-06-06 14:41     ` Nick Garnett
2007-06-06 15:26       ` Øyvind Harboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bqfth1ja.fsf@xl5.calivar.com \
    --to=nickg@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=oyvind.harboe@zylin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).