From: "Joe Porthouse" <jporthouse@toptech.com>
To: <ecos-discuss@ecos.sourceware.org>
Subject: RE: [ECOS] Re: DSR stops running after heavy interrupts. Bug found?
Date: Mon, 10 Apr 2006 13:20:00 -0000 [thread overview]
Message-ID: <MDAEMON-F200604100920.AA2012695md50000000019@toptech.com> (raw)
In-Reply-To: <87r745adh4.fsf@javad.com>
All,
Many thanks for the replies.
I now see my misunderstanding on the intent of the vectors.S line 951,
cmp v1,#CYGNUM_HAL_INTERRUPT_NONE
I also see the bit check in the interrupt_end routine for the isr_ret value.
I am still at a loss for why my change solved my issue. I do believe it is
an issue with servicing an ISR that does not have a DSR.
I am still debugging.
BTW, where is the initial scheduler lock performed when an interrupt is
generated?
Joe Porthouse
Toptech Systems, Inc.
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Sergei Organov
Sent: Monday, April 10, 2006 7:15 AM
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: DSR stops running after heavy interrupts. Bug found?
Nick Garnett <nickg@ecoscentric.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> A little OT while we are at interrupt_end(). Could you please explain
>> why
>>
>> #ifdef CYGPKG_KERNEL_SMP_SUPPORT
>> Cyg_Scheduler::lock();
>> #endif
>>
>> is there at the beginning, -- looks like extra scheduler lock without
>> corresponding unlock for SMP case. If not a bug, it seems a comment
>> would be nice to have there.
>
> In SMP configurations we don't want to claim the scheduler lock in the
> interrupt VSR because it would block interrupts and scheduler
> operations on other CPUs. It also requires a spinlock to be claimed,
> which would require special code to be written -- it's much easier to
> do the job later. In HALs where SMP is supported, the usual scheduler
> lock increment is ifdeffed out.
Ah, now I see, thanks. Seems like non-SMP targets could benefit from
this approach as well, isn't it? Or is there some fundamental difference
here?
I just think that SMP variant makes some things better even for
single-CPU case and thus it could be a good idea to use SMP variant for
single-CPU case in those places. Less ifdefs would be another gain.
>
> Perhaps a comment would be useful, but it seemed like the ifdef
> surrounding it would be sufficient indication that this was for SMP
> only.
Please try to look at it from the POW of a reader of the
interrupt_end(), -- it's clear that it's for SMP only, but it's
absolutely unclear why SMP requires one more scheduler lock. When I
looked at it, I failed to find corresponding unlock(), but didn't pay
much attention as I'm not currently interested in SMP.
I believe your above "In SMP configurations we..." phrase would be a
nice comment for this piece of code.
-- Sergei.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2006-04-10 13:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-05 21:09 [ECOS] DSR stops running after heavy interrupts Joe Porthouse
2006-04-06 6:49 ` Andrew Lunn
2006-04-06 9:02 ` Stefan Sommerfeld
2006-04-06 21:09 ` Joe Porthouse
2006-04-06 21:19 ` Andrew Lunn
2006-04-08 4:18 ` [ECOS] DSR stops running after heavy interrupts. Bug found? Joe Porthouse
2006-04-09 12:33 ` Andrew Lunn
2006-04-10 4:50 ` [ECOS] " Sergei Organov
2006-04-10 9:36 ` Nick Garnett
2006-04-10 10:44 ` Sergei Organov
2006-04-10 10:59 ` Nick Garnett
2006-04-10 11:15 ` Sergei Organov
2006-04-10 13:20 ` Joe Porthouse [this message]
2006-04-10 16:41 ` [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt! Joe Porthouse
2006-04-10 17:20 ` Nick Garnett
2006-04-10 17:44 ` Andrew Lunn
2006-04-10 20:49 ` Joe Porthouse
2006-04-11 4:07 ` Sergei Organov
2006-04-11 8:31 ` Nick Garnett
2006-04-11 4:15 ` Sergei Organov
2006-04-11 8:43 ` Nick Garnett
2006-04-13 7:58 ` [ECOS] How to use the ARM directive DCB in Vectors.S Birahim Larou Fall
2006-04-13 13:28 ` Andrew Lunn
2006-04-13 13:32 ` Birahim Larou Fall
2006-04-21 7:40 ` [ECOS] " Daniel Néri
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=MDAEMON-F200604100920.AA2012695md50000000019@toptech.com \
--to=jporthouse@toptech.com \
--cc=ecos-discuss@ecos.sourceware.org \
/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).