Valid interrupt vectors and the interrupt server

[Christian Mauderer]

Am 17.06.2017 um 20:16 schrieb Joel Sherrill:
> 
> 
> On Jun 17, 2017 11:17 AM, "Christian Mauderer"
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
>     Hello,
> 
>     I had a problem recently, that the interrupt server (for example
>     used in libbsd) caused some odd behaviour on an ARM Cortex BSP. That
>     was solved by the following patch:
> 
>     https://git.rtems.org/rtems/commit/?id=ce3ac00c
>     <https://git.rtems.org/rtems/commit/?id=ce3ac00c>
> 
>     Just today Sichen Zhao had a similar problem on the BBB:
> 
>     https://lists.rtems.org/pipermail/devel/2017-June/018158.html
>     <https://lists.rtems.org/pipermail/devel/2017-June/018158.html>
> 
>     I took a look and it seems that there are a lot of BSPs which don't
>     check for the valid interrupt vector range in their
>     bsp_interrupt_vector_disable/enable functions. Every one of them
>     will most likely have a problems if someone tries to use libbsd or
>     the interrupt server.
> 
>     It also seems that there is no test for the interrupt server. As far
>     as I know, not all targets are able to support the interrupt server
>     depending on the interrupt controller (I'm not exactly sure which
>     ones have support and which doesn't). So if a test for the server
>     would be added, that test will most likely fail on a lot of targets.
> 
>     Has someone an idea how a test for the interrupt server could look
>     like? We would need an interrupt that can be used on every target.
> 
>     Should we mass-change all BSPs to add the check for a valid
>     interrupt? A mass-change could be problematic because it is nearly
>     impossible to test on all targets and it's in a quite critical location.
> 
> 
> Is there anyway a timer method could be used to fake out the interrupt
> occurrence? 
> 
> There is no single interrupt source or interface to get to one.

Hm. OK. I just took another look and noted that there is also not really a test for the normal non-server interrupt install. The only occurrence I found is in a smp test:

https://git.rtems.org/rtems/tree/testsuites/smptests/smpcapture02/init.c?id=ae359a9df#n333

There is about that implemented what you suggested. The test searches for a clock interrupt and replaces it by another (wrapper) handler. Not really an easy solution and I'm not sure whether it would be a good idea to replace the clock tick interrupt with a interrupt server.

By the way: Any such test would most likely only catch a part of the BSPs. For example on the atsam BSP, the odd behaviour normally occurred only a few minutes after the start. Sichens BBB BSP on the other hand would have reached a _Terminate in that case.

But maybe it's the wrong approach. Maybe we should test the bsp_interrupt_vector_enable/disable instead. Any ideas for that test? I think there is no bsp_interrupt_vector_is_enabled() check function? And also if there were one, it would be most likely affected too.

> 
> 
>     Kind regards
> 
>     Christian Mauderer

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.