[ECOS] Re: DSR stops running after heavy interrupts. Bug found?

[Joe Porthouse]

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