public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: David Fernandez <david.fernandez.work@googlemail.com>
To: eCos development list <ecos-devel@ecos.sourceware.org>
Subject: Re: thread2 test gets deadlocked... Is it possible or am I missing some config option?
Date: Tue, 13 Aug 2013 19:19:00 -0000	[thread overview]
Message-ID: <CAA6dH3231xijER8z3SUn57BYsSBCass-qJ8MDfoffKfZPKJzVw@mail.gmail.com> (raw)
In-Reply-To: <CAA6dH30sfbKH5P+ZZNqdsiGXSLWXUE8ewETFpSFCr9yPbN5m9Q@mail.gmail.com>

Never mind,

I've discover a bad interaction between the default ISR/VSR code and
the context switch code... that interrupt_end routine trying to switch
context while on an interrupt stack... That caused that the interrupt
controller code to clear the interrupt priority (for the clok, the
only one going on at the moment), to be skipped.

That would require a bit of complexity to realize and do a proper
context switch on the right stack frame...

By the way, is it me or is this list a bit on holiday... :)

On Tue, Aug 13, 2013 at 2:59 PM, David Fernandez
<david.fernandez.work@googlemail.com> wrote:
> Hi there,
>
> Testing my hal for Cortex-R4, I'm getting a funny behaviour for test
>  kernel/.../thread2. It seems that when two threads have the same
>  priority, there is no timeslicing working (interestingly, the
>  timeslice tests also get deadlocked).
>
> The problem seems to appear because thread#2 preempts thread #1,
> (thread #1 seems to do more API calls than thread #2, but reducing the
> unnecessary ones does not solve the problem), so thread #2 gets
> waiting for thread #1 to increase "q", and thread #1 never gets
> scheduled to realize that "q" has moved to 101, so it can move it to
> 102...
>
> I've added lots of traces (see attached modified thread2.cxx, and the
> trace output below).
>
> Is this test expected to succeed without timeslicing?
> Is it possible that the checks that thread#1 does at that critical
> point might tip off the things to the wrong side?
> Or is it that I might have some wrong configuration option set or unset?
>
> If none of the above... Any idea on what could be wrong?
>
> Regards.
>
> These are the extra output that tries to show what is wrong:
>
> INFO:<Main changing priority for thread #0 to 5.>
> INFO:<Main changing priority for thread #1 to 6.>
> INFO:<Main changing priority for thread #2 to 7.>
> INFO:<Changing Priorities in main done.>
> INFO:<Thread #0 Has q 0 => 1.>
> INFO:<Thread #0 waiting on s0...>
> INFO:<Thread #1 Has q 1 => 2.>
> INFO:<Thread #1 waiting on s1...>
> INFO:<Thread #2 Has q 2 => 3.>
> INFO:<Thread #2 Posts s0.>
> INFO:<Thread #0 waiting on s0 done.>
> INFO:<Thread #0 Has q 3 => 4.>
> INFO:<Thread #0 Posts s1.>
> INFO:<Thread #0 Has q 4 => 5.>
> INFO:<Thread #0 waiting on s0 (1/2)...>
> INFO:<Thread #1 waiting on s1 done.>
> INFO:<Thread #1 Has q 5 => 6.>
> INFO:<Thread #1 changing priority for thread #0 to 9.>
> INFO:<Thread #1 Posts s0.>
> INFO:<Thread #1 Has q 6 => 7.>
> INFO:<Thread #1 changing priority for thread #2 to 3.>
> INFO:<Thread #2 Has q 7 => 8.>
> INFO:<Thread #2 waiting on s2...>
> INFO:<Thread #1 Has q 8 => 9.>
> INFO:<Thread #1 Posts s2.>
> INFO:<Thread #2 waiting on s2 done.>
> INFO:<Thread #2 Has q 9 => 10.>
> INFO:<Thread #2 changing priority for thread #1 to 6.>
> INFO:<Thread #2 Has q 10 => 11.>
> INFO:<Thread #2 changing its priority to 2.>
> INFO:<Thread #2 Has q 11 => 12.>
> INFO:<Thread #2 changing its priority to 7.>
> INFO:<Thread #1 Has q 12 => 13.>
> INFO:<Thread #1 Has q => 100.>
> INFO:<Thread #1 changing priority for thread #2 to 6.>
> INFO:<Thread #1 waiting for 'INFO:<Thread #2 Has q 100 => 101.>
> INFO:<Thread #2 waiting for 'q' to be != 101...>

      reply	other threads:[~2013-08-13 19:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 13:59 David Fernandez
2013-08-13 19:19 ` David Fernandez [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA6dH3231xijER8z3SUn57BYsSBCass-qJ8MDfoffKfZPKJzVw@mail.gmail.com \
    --to=david.fernandez.work@googlemail.com \
    --cc=ecos-devel@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).