From: Marco Tessore <marco.tessore@axelsw.it>
To: xenomai@xenomai.org
Subject: [Xenomai] Kernel freezes in __ipipe_sync_stage
Date: Fri, 20 Jun 2014 11:11:12 +0200 [thread overview]
Message-ID: <53A3FAB0.4050100@axelsw.it> (raw)
Good morning,
I am a fairly new programmer to kernel code developement, and recently I
deal with the development of applications and device drivers using the
Linux / Ipipe / Xenomai platform;
I have a problem with a kernel installed on devices that we have in
production, set up by another programmer.
Please allow me to describe the problem:
the problem is essentially that the kernel rarely, but often enough to
be a problem,
seems to freeze at boot, and from what I have seen with a debugger
hardware - specifically the Lauterbach T32 -
it seems that the stalemate is due to the ipipe code.
The kernel is version 2.6.31 for ARM architecture - specifically a
Freescale iMX257, ARM926EJ-S - with Xenomai 2.5.6 and a not very recent
ipipe patch, of which I did not know the version, i presume the one
included in the xenomai archive.
The stalling seems to occur in the function __ ipipe_sync_stage, in
kernel/ipipe/core.c, and can occur at various times during the system boot.
As an example, I describe the stack that I could observe during one of
these stall conditions:
__ipipe_mach_get_tsc
xntimer_tick_aperiodic
xintr_clock_handler
__ipipe_sync_stage
ipipe_suspend_domain
__ipipe_walk_pipeline
__ipipe_restore_pipeline
xnarc_next_htick_shot
clockevents_program_event
tick_dev_program_event
tick_program_event
hrtimer_interrupt
mxc_timer_interrupt
handle_IRQ_event
handle_level_irq
asm_do_IRQ
__ipipe_sync_stage <-- loop
ipipe_suspend_domain
__ipipe_walk_pipeline
__ipipe_restore_pipeline_head
xnpod_enable_timesource
xnpod_init
__native_skin_init
do_one_initcall
kernel_init
The problem seems to occur within the first call to the function
__ipipe_sync_stage (as indicated by the arrow),
in particular it seems that we never match the exit condition of the
innermost "while" loop:
((submask = p-> irqpend_lomask [level])! = 0).
It seems that after the reset of p->irqpend_lomask[level], during the
execution of interrupt service routine, timer interrupt I think,
it seems that the flag, or some other flags in the variable returns set,
and this seems to cause the lock.
Given that, although I had an idea of the general mechanisms that drive
ipipe, I am not able to grasp the implementation details,
in particular I cannot state when and where that flags are set, I
presume when hw interrupt occours.
I was wondering if you could give me an idea of what could cause
stalling or if you had any suggestions on how to get out, making
advancing the kernel in a clean state.
Thank you in advance for any suggestions you could give me,
kind regards
Marco Tessore
next reply other threads:[~2014-06-20 9:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 9:11 Marco Tessore [this message]
2014-06-20 11:52 ` [Xenomai] Kernel freezes in __ipipe_sync_stage Gilles Chanteperdrix
2014-06-20 12:18 ` Marco Tessore
2014-06-20 12:25 ` Gilles Chanteperdrix
2014-06-24 16:41 ` Marco Tessore
2014-06-24 17:10 ` Philippe Gerum
2014-06-25 7:50 ` Marco Tessore
2014-06-25 8:39 ` Philippe Gerum
2014-07-02 16:36 ` Marco Tessore
2014-07-02 17:41 ` Gilles Chanteperdrix
2014-07-09 16:09 ` Marco Tessore
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=53A3FAB0.4050100@axelsw.it \
--to=marco.tessore@axelsw.it \
--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.