On Fri, Jun 19, 2009 at 10:00, Robin Getz wrote:
> On Fri 19 Jun 2009 08:34, Mike Frysinger pondered:
>> On Fri, Jun 19, 2009 at 08:30, Robin Getz wrote:
>> > On Fri 19 Jun 2009 05:33, Li Yi pondered:
>> >> On Fri, 2009-06-19 at 05:04 -0400, Mike Frysinger wrote:
>> >> > off the top of my head,
>> >> > core Blackfin interrupt code shouldnt be triggering exceptions in the
>> >> > first place. if our core code paths are not causing problems, then
>> >> > this shouldnt really be an issue. but if our core code paths are
>> >> > triggering exceptions, we will need to make sure that it isnt in a
>> >> > place where we are using the disabled interrupt aspect to work around
>> >> > anomalies (e.g. save/restore order of loop counter registers) and that
>> >> > we dont return to that location with global interrupts enabled when
>> >> > they arent before (i.e. we have to save/restore the IPEND[4] state).
>> >> > and the xenomai ipipe code has to be similarly aware of these
>> >> > anomalies.
>> >> >
>> >> > the new code really should look like:
>> >> > /* Clear IPEND[4] (global interrupt disable bit) by the special
>> >> > * sequence of pushing RETI onto the stack. This way we can lower
>> >> > ourselves to IVG5 even if the exception was taken after the
>> >> > interrupt handler was called but before it got a chance to enable
>> >> > global interrupts itself.
>> >> > */
>> >> > [--sp] = reti;
>> >> > sp += 4;
>> >>
>> >
>> > Normally we turn interrupts off with:
>> >
>> > CLI Dreg ;
>> >
>> > The Disable Interrupts instruction globally disables general interrupts by
>> > setting IMASK to all zeros. In addition, the instruction copies the
>> > previous contents of IMASK into a user-specified register in order to
>> > save the state of the interrupt system.
>>
>> we are talking about IPEND here, not IMASK. cli/sti only operate on IMASK.
>
> Right -- but the same could occur. We have atomic operations (due to cli/sti),
> but then we turn interrupts back on for single stepping? Isn't that a
> problem?
no, because we explicitly set the IMASK with sti when lowering
ourselves. we are only talking about the case where we use
exception_to_level5 -- we're at EVT3 and want to lower ourselves to
EVT5.
ENTRY(_ex_trap_c)
...
P5.h = _exception_to_level5;
P5.l = _exception_to_level5;
p4.l = lo(EVT5);
p4.h = hi(EVT5);
[p4] = p5;
...
r6 = 0x3f;
sti r6;
raise 5;
...
> The IPEND[4] bit is used by the Event Controller to temporarily disable
> interrupts on entry and exit to an interrupt service routine.
>
> Normally - Before the first instruction in the interrupt vector starts
> execution, IPEND[4] is set to disable all interrupts. This allows context
> save to be atomic. It is cleared (higher priority interrupts enabled) when
> the return address in RETI is saved ([--SP] = RETI).
>
> On context restore, popping RETI (RETI = [SP++]) will set IPEND[4], disabling
> all interrupts. When the RTI instruction executes, it re-enables interrupts
> by clearing IPEND[4].
yes
> But I didn't think that code that we write should be playing with that? - and
> that we should be doing CLI/STI.
we arent, which is also what i said ... but the xenomai code is and it
does raise a general stability question of our core code
> Looks like we are doing that in some of our assembly code -- but the most
> comes from RESTORE_CONTEXT or SAVE_CONTEXT macros...
that is the natural order of things. when an interrupt occurs,
IPEND[4] is set automatically so we have to clear/restore it in our
save/restore macros
>> the issue at hand is:
>> - the core gets an interrupt (say IVG8)
>> - IPEND[4] is set by the core automatically
>> - the handler at EVT8 is called
>> - before the handler can push RETI onto the stack (and thus clear
>> IPEND[4]), an exception is triggered
>
> It's not just an exception - it is something that needs to defer to IRQ5 - an
> error condition, which would call panic() anyway.
in general, there is going to be latency if a hardware error is
signaled before we clear IPEND[4], but that isnt what Yi is concerned
with here. we basically set ourselves up for an infinite hang by
attempting to lower ourselves across the IVG4 barrier (IVG3 to IVG5).
>> - the exception handler at EVT3 is called
>> - we attempt to lower ourselves to EVT5
>> - we hang forever because IPEND[4] is still set
>>
>> while this may not be the exact sequence of events Yi is seeing with
>> xenomai, i think it's similar. the xenomai code pushs/pops RETI on
>> the stack so as to manually manage IPEND[4]
>
> I guess - is this the right way to do it in the xenomai code? Can't it do the
> same with CLI/STI?
>
>> and somewhere in there, it
>> causes an exception with IPEND[4] still set.
>
> I grok the issue - and think the fix is OK - but I'm just wondering if there
> is a deeper problem...
there is also a deeper problem, but Yi is trying to fix multiple
things -- first an infinite hang in our core code while also trying to
find the problem in the xenomai ipipe code
-mike
_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel@blackfin.uclinux.org
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
