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