Am 17.06.2017 um 20:16 schrieb Joel Sherrill: > > > On Jun 17, 2017 11:17 AM, "Christian Mauderer" > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel