On Fri, 2009-06-19 at 15:26 -0400, Mike Frysinger wrote: > On Fri, Jun 19, 2009 at 12:25, Bernd Schmidt wrote: > > Mike Frysinger wrote: > >> - before the handler can push RETI onto the stack (and thus clear > >> IPEND[4]), an exception is triggered > > > > This shouldn't happen, at least not with any exception other than a CPLB > > miss. > > right, the likelihood of this happening in *our* code is very very > small, but it is still non-zero. with xenomai ipipe code
Actually, I see no valid reason why the interrupt pipeline and/or the RTOS code on top of it should be allowed to raise an exception while the global disable bit is raised. We do have a strong requirement to minimize the interrupt latency to its bare minimum, so allowing real-time tasks to run while IPEND[4] is raised would be a showstopper, causing the worst-case latency to skyrocket badly. Again, the Xenomai core (i.e. the RTOS on top of the CONFIG_IPIPE stuff) only uses CLI/STI to mask hw interrupts when required. > (and perhaps > other people's code), it may be much higher. i think our core code > should be able to recover from this though regardless of what other > people are doing. > > perhaps we need to add another field to our core PDA to save IPEND so > that when we do return from exception_to_level5, we can test to see if > we need to restore IPEND[4] to the state before the exception > occurred. > -mike > > _______________________________________________ > Uclinux-dist-devel mailing list > Uclinux-dist-devel@blackfin.uclinux.org > https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel -- Philippe. _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
