From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7266 invoked by alias); 13 Aug 2013 19:19:19 -0000 Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org Received: (qmail 7255 invoked by uid 89); 13 Aug 2013 19:19:18 -0000 X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.2 Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 19:19:17 +0000 Received: by mail-pa0-f48.google.com with SMTP id kp13so9166656pab.7 for ; Tue, 13 Aug 2013 12:19:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.232.8 with SMTP id tk8mr6025853pac.121.1376421555499; Tue, 13 Aug 2013 12:19:15 -0700 (PDT) Received: by 10.70.50.129 with HTTP; Tue, 13 Aug 2013 12:19:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 19:19:00 -0000 Message-ID: Subject: Re: thread2 test gets deadlocked... Is it possible or am I missing some config option? From: David Fernandez To: eCos development list Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-08/txt/msg00003.txt.bz2 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 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:
> INFO:
> INFO:
> INFO: > INFO: 1.> > INFO: > INFO: 2.> > INFO: > INFO: 3.> > INFO: > INFO: > INFO: 4.> > INFO: > INFO: 5.> > INFO: > INFO: > INFO: 6.> > INFO: > INFO: > INFO: 7.> > INFO: > INFO: 8.> > INFO: > INFO: 9.> > INFO: > INFO: > INFO: 10.> > INFO: > INFO: 11.> > INFO: > INFO: 12.> > INFO: > INFO: 13.> > INFO: 100.> > INFO: > INFO: 101.> > INFO: