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_han
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 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_g
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
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
Gilles Chanteperdrix wrote:
> 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
Gilles Chanteperdrix wrote:
> 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
Jan,
>>> BTW, do you have the nucleus option "disable priority coupling" set or
>>> not in your config (the latter is default, ie. it's on)? The other bug
>>> is triggered when prio coupling is on, and doesn't appear while it's
>>> off. Just to collect more patterns...
>> CONFIG_XENO_OPT_PRIOCPL=y
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)
Gilles Chanteperdrix wrote:
> 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
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)
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:
> 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 descri
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
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 *if*
> you
Steven Scholz wrote:
> Jan,
>
>> BTW, do you have the nucleus option "disable priority coupling" set or
>> not in your config (the latter is default, ie. it's on)? The other bug
>> is triggered when prio coupling is on, and doesn't appear while it's
>> off. Just to collect more patterns...
>
> CO
Jan,
> BTW, do you have the nucleus option "disable priority coupling" set or
> not in your config (the latter is default, ie. it's on)? The other bug
> is triggered when prio coupling is on, and doesn't appear while it's
> off. Just to collect more patterns...
CONFIG_XENO_OPT_PRIOCPL=y
Steven
Steven Scholz wrote:
> 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 peri
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
CONFIG_IPIPE_TRACE_MCOUNT=y
CO
Steven Scholz wrote:
> 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 peri
Steven Scholz wrote:
> 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 per
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
> buffer
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! ;-)
>
On Fri, 2007-02-23 at 14:56 +0100, Steven Scholz wrote:
> Philippe,
>
> >> I tried! Attached the patch I used. Since teh scheduler hangs I can't use
> >> normal printk(), right?
> >>
> >> *ipipe_current_domain != ipipe_root_domain !
> >> *ipipe_current_domain = c01fc2c0
> >> *ipipe_root_domain
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, prior
Philippe,
>> I tried! Attached the patch I used. Since teh scheduler hangs I can't use
>> normal printk(), right?
>>
>> *ipipe_current_domain != ipipe_root_domain !
>> *ipipe_current_domain = c01fc2c0
>> *ipipe_root_domain= c01af2c0
>>
>> But I don't get the output of __backtrace()!
>
> Befo
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|--
On Fri, 2007-02-23 at 14:50 +0100, 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 (p
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, 2
Philippe Gerum wrote:
> 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
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
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 include/linu
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, 2
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 period, priority 99)
RTH|-lat min
34 matches
Mail list logo
