This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: DSR stops running after heavy interrupts.
On Thu, Apr 06, 2006 at 05:08:45PM -0400, Joe Porthouse wrote:
> Stefan, thanks. I'm glad to know I'm not the only one experiencing this
> problem.
>
> I have made a little more progress.
>
> I still can't explain the issues with the code listed in my first message
> with the code checking the return value from the ISR, but I believe it is
> somehow working correctly. I still believe there may be a problem with R4
> being checked instead of R0. I did verify that the memory was the same as
> my code window, as well as the flash image.
>
> This is what I did find.
>
> DSR calls are being added to the table... thousands of them... just not
> getting serviced. The all calls that lead to "call_pending_DSRs" seem to
> originate from the unlock_inner() routine getting called. This routine
> stops getting called when the problem occurs. (you can see the logic below)
>
>
> inline void Cyg_Scheduler::unlock()
> {
> // This is an inline wrapper for the real scheduler unlock function in
> // Cyg_Scheduler::unlock_inner().
>
> // Only do anything if the lock is about to go zero, otherwise we simply
>
> // decrement and return. As with lock() we do not need any special code
> // to decrement the lock counter.
>
> CYG_INSTRUMENT_SCHED(UNLOCK,get_sched_lock(),0);
>
> HAL_REORDER_BARRIER();
>
> cyg_ucount32 __lock = get_sched_lock() - 1;
>
> if( __lock == 0 )
> unlock_inner(0);
> else
> set_sched_lock(__lock);
>
> HAL_REORDER_BARRIER();
> }
>
> Upon examination the __lock value is "6" when unlock() is called at the end
> of the ISR, thus unlock_inner never gets called. If I get the variable
> location in the get_sched_lock() back to 1, my DSR calls resume.
> Mmmmmmm....
>
> So somehow locks are being done without unlocks. I am at a loss to figure
> out how this is occurring since I do not make lock calls in any of my code.
> Could interrupt preemption somehow be occurring? Does the
> hal_disable/enable interrupt calls mess with the lock?
>
> Any good ideas on how to track this down?
Kernel instrumentation.
CYG_INSTRUMENT_SCHED(UNLOCK,get_sched_lock(),0);
locks and unlocks are logged. See if you can find a case of a lock
without an unlock.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss