RTEMS scheduler bug ?

[Jonathan Brandmeyer]

What methods are available for altering an interrupt's priority in
RTEMS?  There's some mention of supporting up to 256 priorities, but
no mention of how to adjust an interrupt's priority through the
interrupt manager.  It looks like I've got to use the interrupt
controller's registers directly, and it isn't clear that RTEMS would
respect the modification.

On Thu, Apr 4, 2019 at 7:24 AM Joel Sherrill <joel at rtems.org> wrote:

> Thanks Andrei! I am glad you are past this but let's do a post-game analysis of what
> could be better next time so no one else suffers as much. These are random ideas
> and I am open to more.
>
> + Could this be detected at run-time during setup with a debug option?

For machine-automated detection... is there *any* way to install an
NMI handler via the Interrupt Manager?  It looks like all of the user
interrupt handlers go through a supercore-provided wrapper, even on
v7-M.  If NMI's are never installable via the interrupt manager, then
RTEMS could have a DEBUG-guarded check of the priority level before
handing off to the user's code.  Combine that with some policy that if
the user wants to install their own NMI handler, that they must do so
themselves.  On v7-M that's pretty easy thanks to the hardware's
automatic register stacking.  Then you have three categories of
interrupts:
- NMI's handled by RTEMS to detect fatal errors.  Users can receive
notification through the fatal notification hook in a user extension.
The CPU Architecture Supplement enumerates them.
- NMI's handled by user code.  These must be installed by the user in
a platform (or even processor)-specific way.  User's should not
attempt to replace NMI's owned by RTEMS for fatal errors.
- Interrupts which may safely use the RTEMS services enumerated by the
Interrupt Manager (the 8.3.2 list).  These are installed and managed
through the interrupt manager.

> + Could this be written up in the BSP Guide so at least there is a place to reference?
> Perhaps in a generic section on dealing with interrupt controllers
>
> I don't think this is specifically an ARM issue. It is just easy to do on the ARM.
> I recall people doing similar things with high priority interrupts and NMI's in the
> past.
>
> Any other ideas? My goal is always to try to prevent people from suffering over
> and over from the same mistakes.
>

There's some room for improvement in the documentation. 8.2.3 in the
interrupt manager manual discusses the risks involved with NMI's.  The
trouble is that NMI is overloaded to mean subtly different things on
different processor architectures. 3.5 in the CPU Architecture
Supplement isn't particularly clear about the differences between
v4T/v7-A/R and the -M profile interrupt models.  Some wishlist ideas
for the CPU Architecture Supplement:

- Describe exactly how an RTEMS NMI relates to the -M and the v4T models.
  - Call out the semantic difference between the -M profile NMI vector
and an RTEMS NMI.
  - Make that 0x80 priority level available via a #define, maybe in
score/armv7m.h
  - Describe how to map the RTEMS NMI priority level for the ARMv7-M
port to an interrupt priority in CMSIS.
  - Describe how the 3.5.1 interrupt levels relate to NVIC and GIC
interrupt priorities.  IIUC, the level-1 interrupt is only supported
on GICv2, only on the Cyclone-V BSP, and its chosen by directing the
interrupt to the core's FIQ handler.  So for example, a xilinx-zynq
fabric FIQ request will end up just being treated as a fatal exception
by RTEMS.
- Call out which exception vectors are routed through the user
extension point for fatal error detection.
- Document that ARM uses the new interrupt handling model provided by
the irq-extension.h header.

Some ideas for the RTEMS Classic API manual:

- Looking at the 23.2.12 fatal error extension, I'm a little confused
about how to safely install my own fatal error hook in such a way that
the BSP's fatal error hook still gets called.
- Document the irq-extension.h interface.

-- 
Jonathan Brandmeyer