This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: On ecos interrupt process


Hi,

That was quite helpful diagram Nick. I have few naive
doubts again, listed below.

>       |
>  switch to interrupt stack
>       |
>  [enable interrupts](1)
>       |
>  call ISR ---------|
>                    |
>               handle device
>                    |
>             acknowledge interrupt(2)
>                    |
>              request DSR run
>                    |
>       |-------------
>       |
>  switch back to thread stack
>       |
>  call interrupt_end() ------|
>                             |
>                          post DSR
>                             |
>                         unlock scheduler ----|
>                                              |
>                                        switch to
> interrupt stack(4)
>                                              |
>                                        [enable
> interrupts](3)
>                                              |
>                                         call any
> DSRs
>                                              |
>                                        [restore
> interrupt state]
>                                              |
>                                        switch back
> to thread stack(5)
>                                              |
>                             |----------N-new thread?
>                             |                Y
>                             |                |
>                             |           switch
> context

We will reach this point only via unlock_inner(0)
call.
Now I am bit confused here, seems like I am missing
something in understanding things.

The schedlock won't be zeroed out till the "switched
out" thread is "switched in" again and we return back
into same place in execution here. That means that DSR
processing can remain pending for a long time!!!!

As per unlock_inner code, zero_sched_lock will be
called only if new_lock was zero in current invocation
of unlock_inner(new_lock), and the next switched-in
thread, might not have new_lock value as zero, in it's
context (it might have been taken off last time
because of reschedule call).


>                             |           {enable
> interrupts}
>                             |                |
>                             |           return from
> switch
>                             |           {restore
> interrupt state}
>                             |                |
>                             |----------------|
>                             |
>                       zero scheduler lock
>                             |
>       |---------------------|
>       |
>  restore CPU state
>  {enable interrupts}

> controller. In particular,
> how a pending unacknowledged interrupt is handled.
> If the hardware
> behaves sensibly, then with the enable at (1), fresh
> interrupts will
> only be permitted when the current interrupt is
> acknowledged at (2).
> Poorly behaving hardware would cause an immediate
> re-interrupt at (1).

What if the hardware is *not sensible* as per above
explanation? what can be the repurcussions of this
then? I guess the interrupt stack will be overflown.
Will there be any other issue apart from this?
Just wondering, if deploying such kind of hardware
will mean *dooomed* for the places where it is
deployed? Has anyone on the list come across such kind
of *not sensible* hardware so far?

brij


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]