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

[Andrew Lunn <andrew@lunn.ch>]

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