Hi Gilles,
Ok, found the bug (actually, Philippe did), as almost expected, the way
it is related to the latency program period is not really obvious. The
bug is that in the macro irq_handler in entry-armv.S, the return value
(in r0) of __ipipe_grab_irq is overriden by the subsequent call to
Steven Scholz wrote:
Gilles Chanteperdrix wrote:
Steven Scholz wrote:
Hi Gilles,
Ok, found the bug (actually, Philippe did), as almost expected, the way
it is related to the latency program period is not really obvious. The
bug is that in the macro irq_handler in entry-armv.S, the
Steven Scholz wrote:
Hi,
i pick up this issue again.
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us
On Fri, 2007-02-23 at 12:27 +0100, Steven Scholz wrote:
#ifdef CONFIG_IPIPE
if (unlikely(!ipipe_root_domain_p))
return;
#endif /* CONFIG_IPIPE */
When stepping trough I only see him getting into schedule() but leaving
it in the above lines and in
On Fri, 2007-02-23 at 14:16 +0100, Gilles Chanteperdrix wrote:
I do not think to remember that there are cases where calling schedule
from a real-time context is done by Xenomai, so maybe you can call panic
in schedule instead of returning. I will try and trig a tracer freeze
and dump the
Steven Scholz wrote:
Hi,
i pick up this issue again.
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us
Gilles,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat min|-lat
Steven Scholz wrote:
Gilles,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat
Gilles,
Sure but I would still not expect the system to hang!
As I said missing a deadline is bad but ok.
But hanging the whole system is not quite ok.
I want this bug solved too, especially since I am not sure that we will
only see it with too short periods.
Makes us two! ;-)
I would
Philippe,
But I don't get the output of __backtrace()!
Before calling your backtrace helper, try adding:
ipipe_set_printk_sync(ipipe_current_domain);
And then use printk() instead of my_printk()?
Yes, switching this on is a brute force attempt to bypass any
bufferization and allow
Steven Scholz wrote:
Hi,
schedule. Anyway, I think the tracer will give better results than a
simple backtrace.
Ok. Thanks.
So what exactly shell I do? I have never worked with the tracer.
Just enabled
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_TRACE=y
CONFIG_IPIPE_TRACE_ENABLE=y
Steven Scholz wrote:
Jan,
So what exactly shell I do? I have never worked with the tracer.
Start here: http://www.xenomai.org/index.php/I-pipe:Tracer
I haven't followed all details (while hacking on other bugs :)), but you
have two options to catch a trace: the one described on that page
Hi all,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat min|-lat
Steven Scholz wrote:
Hi all,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat
14 matches
Mail list logo
