lockup in delta chain using signal timers
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Feb 17 08:30:05 UTC 2016
Hello Martin,
which RTEMS version do you use (Git commit)?
On 15/02/16 16:53, Martin Werner wrote:
> We're seeing an issue in RTEMS where heavy use of signal timers causes
> the internal RTEMS delta chain (_Watchdog_Ticks_chain) to end up with a
> self-referencing node, which subsequently blocks insertion and locks the
> application.
If you build RTEMS with the --enable-rtems-debug option, do you get an
assertion failure?
>
> I've cobbled together a testcase[1] based on samples/ticker, and have
> seen the issue when running on qemu/i386.
>
> Is this testcase valid, or is the usage of the signal timers here
> incorrect?
I was not able to reproduce the described error (self-referencing node),
instead the test program overloaded the interrupt service with a delta
chain length of about 300 so that the clock tick interrupt service time
exceeded the clock tick interval.
>
> If it is valid, does anyone have a suggestion as to what may be the core
> issue, assuming that the delta chain behaviour is only a symptom?
I fixed two bugs in the delta chain code recently, but they were not
related to a self-referencing node problem. You can get a
self-referencing node, if you do a double insert or remove from the
chain. However, this should be detected by debug asserts.
>
> We originally saw this issue on our custom or1k hardware, where due to
> various circumstances it seems much more easy to provoke (there with
> only 3 threads), and from there have tracked it back to something which
> seems to be non-or1k-specific.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the users
mailing list