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

[Satish Kumar <satish at bvt dot sc dot sanyo dot co dot jp>]

btw, all this i m trying with ICACHE and DCACHE disabled. is this in any
way affecting my work.

satish


On Wed, 24 Sep 2003 10:02:14 +0900
Satish Kumar <satish@bvt.sc.sanyo.co.jp> wrote:

> well, i am currently testing clocktruth.cxx program, and i m stuck in
> this problem past 2-3 weeks..my timers are working perfectly fine, they 
> generate an periodic interrupt as required, and the ISR routine is
> called but not the DSR routine. this fails to intialize the rtc->tick
> and my rtc->counter is always 0 when read.
>      well, now i have even changed my clock to run at 10ms, instead of 
> 10us as stated earlier..i just don`t get where could be the problem..i
> tried all possibilities..but still not able to solve this issue.
> 
> i even upgraded my gcc to 3.3, but still no success.
> 
> some one plz help,
> thanks,
> satish
> 
> 
> 
> On 23 Sep 2003 11:01:16 +0100
> Nick Garnett <nickg@ecoscentric.com> wrote:
> 
> > 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
> 
> -- 
> Satish Kumar <satish@bvt.sc.sanyo.co.jp>
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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


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