Re: [ECOS] clock interrupt fails to call unlock_inner()

[Nick Garnett <nickg at ecoscentric dot com>]

Satish Kumar <satish@bvt.sc.sanyo.co.jp> writes:

> Hi,
>       when the clock interrupt takes place, my
> hal_interrupt_stack_call_pending DSRs func is not called. following is
> the intermediate path when an clock interupt takes place.
> i.e
>     when i enter into the interrupt_end() func, following steps are
> followed:
>           Set_Save_Context()--|
>                               post_DSR()
>           Set_Save_Context()--|
>                 |
>            Get_Current_Thread()----|
>                 |             Set_Save_Context()
>                                    |
>                               Get_Sched_lock()
>                                    |
>                              unlock()(fails to call unlock_inner() func)  
>                                    |----
>                                         |
>                                     Set_Sched_lock()...!!!!!
>                                         |
>                                    |-----
>                               unlock()
>            Get_Current_Thread()----|
>                  |
>          Set_Save_Context()
> 
> 
> Now the problem is that when the unlock() func is stepped in the
> identifier "__lock" is  undefined and hence Set_Sched_lock()
> is called..instead of unlock_inner() func which is responsible for
> invoking hal_interrupt_stack_call_pending_DSRs.
> 
> this fails to call the DSRs from RealTimeClock and hence i fail to test
> any of my program which is dependent on the clock interrupt.
> 
> well my dsr_list contains the data entry for the clock interrupt
> generated and also the interrupt vector no: are all correct.
> 
> 
> so, is there somethin which i m failin to understand.

Just because in the particular instance of a call to interrupt_end()
that you traced the scheduler lock was >0 does not mean that this is
always the case.

Instead of wasting time trying to trace through the kernel, I suggest
you look hard at the code you have written to program the timer
device. The bug is almost certainly in there. You have already told us
that you are trying to run the clock at a ridiculously high
frequency. Try running it at the standard 10ms rate rather than
10us. At 10us per tick the CPU is probably just taking one
interrupt after another and not making any other progress.

Also try running some of the standard test programs such as tm_basic
and clocktruth. These are much better tests of system behaviour than
the examples.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss