From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Henri Roosen <henriroosen@gmail.com>
Cc: "Xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai] xnarch_xchg infinite loop
Date: Mon, 20 Jan 2014 21:40:15 +0100 [thread overview]
Message-ID: <52DD89AF.4090905@xenomai.org> (raw)
In-Reply-To: <CANKLDms3aXrSoov7Z9T2JBN6fpmuh43LCQ0RUEETrDAYr3=1dA@mail.gmail.com>
On 01/20/2014 11:02 AM, Henri Roosen wrote:
> On Mon, Jan 20, 2014 at 10:48 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On 01/20/2014 09:31 AM, Henri Roosen wrote:
>>> Hi all,
>>>
>>> We have the problem that (hot-)rebooting our Xenomai system fails every 1
>>> out of 10 times.
>>>
>>> The system is an ARM iMX6Solo (Cortex-A9) running Xenomai 2.6.2.1 and
>>> kernel 3.0 (freescale branch).
>>>
>>> When the system hangs at reboot, it is in an infinite loop in the Xenomai
>>> atomic exchange implementation, with STREX always returning 1:
>>>
>>> __xnarch_xchg
>>> S:0xC0094B2C : ADD r3,r6,#0x890
>>> S:0xC0094B30 : LDREX r2,[r3]
>>> S:0xC0094B34 : STREX r1,r9,[r3]
>>> S:0xC0094B38 : TEQ r1,#0
>>> S:0xC0094B3C : BNE {pc}-0xc ; 0xc0094b30
>>>
>>> Does anyone know what is causing the STREX to always return 0 and why it
>>> might get into this state?
>>
>> Normally, strex fails if "something else" stores data in between ldrex
>> and strex. Do you have the full stack trace?
>>
>
> Thank you for your reply Gilles. Please find the stacktrace below:
>
> #0 __xnarch_xchg( size = 4, x = 3204479504, ptr = <Value optimised away by
> compiler> ) at atomic_asm.h:79
> #1 xnintr_irq_handler( irq = 260, cookie = (void*) 0xBF0079E8 ) at
> atomic_asm.h:93
> #2 __ipipe_sync_stage() at core.c:1301
> #3 ipipe_suspend_domain() at core.c:856
> #4 __ipipe_walk_pipeline( pos = (struct list_head*) 0xC0463884 ) at
> core.c:797
> #5 __ipipe_handle_irq( irq = 98, flags = 0 ) at ipipe.c:564
> #6 __ipipe_grab_irq( irq = <Value optimised away by compiler>, regs =
> (struct pt_regs*) 0xCC897DD8 ) at ipipe.c:618
> #7 [__irq_svc+0x40]
I do not really see what is going on. However, how come you have a
driver still running while rebooting? Do you not remove the drivers
before rebooting? Also, __irq_svc means you received an interrupt while
in svc mode, so, it would be interesting to know what is below
__irq_svc. I believe you can know that by adding a call to show_stack
(and preferably build the kernel with frame pointers). The trick will be
to avoid getting a show_stack on every interrupt.
Regards.
--
Gilles.
next prev parent reply other threads:[~2014-01-20 20:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 8:31 [Xenomai] xnarch_xchg infinite loop Henri Roosen
2014-01-20 9:48 ` Gilles Chanteperdrix
2014-01-20 10:02 ` Henri Roosen
2014-01-20 20:40 ` Gilles Chanteperdrix [this message]
2014-01-22 8:31 ` Henri Roosen
2014-01-22 10:47 ` Gilles Chanteperdrix
2014-01-22 14:49 ` Henri Roosen
2014-01-22 20:20 ` Gilles Chanteperdrix
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=52DD89AF.4090905@xenomai.org \
--to=gilles.chanteperdrix@xenomai.org \
--cc=henriroosen@gmail.com \
--cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.