This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Re: DSR stops running after heavy interrupts. Bug found?
- From: "Joe Porthouse" <jporthouse at toptech dot com>
- To: <ecos-discuss at ecos dot sourceware dot org>
- Date: Mon, 10 Apr 2006 09:20:13 -0400
- Subject: RE: [ECOS] Re: DSR stops running after heavy interrupts. Bug found?
- Dkim-signature: a=rsa-sha1; c=simple; d=toptech.com; s=MDaemon; t=1144675214; x=1145884814; q=dns; h=DomainKey-Signature: Received:Reply-To:From:To:Subject:Date:Organization:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To:Thread-Index: Message-ID; b=e+t0/B1aVpkaTDcFg1eTlN0wu+AB5IuQyW5uytZ2ZmcJ5+Eyltj 2kEbQd3mia+io94b7uwo4jiX5oXBLPiibboOFO985EXPh1aQAlcTojHilF9rxJYZ avAj+eanXcVeg5/joLQjKG07vMdERlChoQFaPmkQM0vXCr2a7s84U83M=
- Reply-to: <jporthouse at toptech dot 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