[Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

Hi,

I'm still trying to debug ipipe on the mini2440 board (linux 2.6.35.9 +
ipipe 1.18.01 + Gilles' ARM patches). Now I encounter the following
problem. If any Xenomai skin module is loaded the system hangs. In fact,
it goes into sleep with interrupts off.

The sleep was in pm_idle() and it is done correctly. The problem lies
somewhere else. I tried to use busy-loop instead of sleep, like that:

- if (hlt_counter) {
+ if (1 || hlt_counter) {

in cpu_idle() (arch/arm/kernel/process.c). Now I found that the loop
"while (!need_resched())" never exits, need_resched() is always
returning false and there are no interrupts. Looks like the timer
interrupt either stops ticking or is masked out since xenomai skin is
loaded.

Can you please help to debug it?

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/05/2011 02:20 PM, Alexey Galakhov wrote:
> Hi,
> 
> I'm still trying to debug ipipe on the mini2440 board (linux 2.6.35.9 +
> ipipe 1.18.01 + Gilles' ARM patches). Now I encounter the following
> problem. If any Xenomai skin module is loaded the system hangs. In fact,
> it goes into sleep with interrupts off.
> 
> The sleep was in pm_idle() and it is done correctly. The problem lies
> somewhere else. I tried to use busy-loop instead of sleep, like that:
> 
> - if (hlt_counter) {
> + if (1 || hlt_counter) {
> 
> in cpu_idle() (arch/arm/kernel/process.c). Now I found that the loop
> "while (!need_resched())" never exits, need_resched() is always
> returning false and there are no interrupts. Looks like the timer
> interrupt either stops ticking or is masked out since xenomai skin is
> loaded.
> 
> Can you please help to debug it?

You should make sure that pm_idle == default_idle. In this case,
__ipipe_halt_root is called instead of arch_idle, and everything should
work.

> 
> --
> Alex
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
> 


-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 02:20 PM, Alexey Galakhov wrote:
>> Hi,
>>
>> I'm still trying to debug ipipe on the mini2440 board (linux 2.6.35.9 +
>> ipipe 1.18.01 + Gilles' ARM patches). Now I encounter the following
>> problem. If any Xenomai skin module is loaded the system hangs. In fact,
>> it goes into sleep with interrupts off.
>>
>> The sleep was in pm_idle() and it is done correctly. The problem lies
>> somewhere else. I tried to use busy-loop instead of sleep, like that:
>>
>> - if (hlt_counter) {
>> + if (1 || hlt_counter) {
>>
>> in cpu_idle() (arch/arm/kernel/process.c). Now I found that the loop
>> "while (!need_resched())" never exits, need_resched() is always
>> returning false and there are no interrupts. Looks like the timer
>> interrupt either stops ticking or is masked out since xenomai skin is
>> loaded.
>>
>> Can you please help to debug it?
> You should make sure that pm_idle == default_idle. In this case,
> __ipipe_halt_root is called instead of arch_idle, and everything should
> work.
I double-checked this. Yes, __ipipe_halt_root is called.

If I just run the kernel "as is", it hangs with the following stack:

s3c24xx_default_idle (sleep is done correctly, no IRQs are coming!)
arch_idle
__ipipe_halt_root
cpu_idle

To ensure the timer is not stopped when CPU going to sleep, I hacked
s3cxx_default_idle by replacing its entire contents with

for (i = 0; i < 10000; ++i) { __asm__ __volatile__ ("nop"); }
return;

Now I'm sure timers aren't blocked by the sleep command. Now the
debugger shows that it enters __ipipe_halt_root and s3cxx_default_idle
over and over again, nothiung else seems to happen.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
> You should make sure that pm_idle == default_idle. In this case,
> __ipipe_halt_root is called instead of arch_idle, and everything should
> work.
May it be caused by the following code from plat-samsung/time.c ?

static inline void set_dec(unsigned long reload)
{
        __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
> On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
>> You should make sure that pm_idle == default_idle. In this case,
>> __ipipe_halt_root is called instead of arch_idle, and everything should
>> work.
> May it be caused by the following code from plat-samsung/time.c ?
> 
> static inline void set_dec(unsigned long reload)
> {
>         __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */

Try adding:

if (reload > 0xffff)
	reload = 0xffff;

before the raw_writel.

-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>> May it be caused by the following code from plat-samsung/time.c ?
>>
>> static inline void set_dec(unsigned long reload)
>> {
>>         __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
>> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */
> Try adding:
>
> if (reload > 0xffff)
> 	reload = 0xffff;
>
> before the raw_writel
No effect. It may make sense but does not fix this bug.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>>> May it be caused by the following code from plat-samsung/time.c ?
>>>
>>> static inline void set_dec(unsigned long reload)
>>> {
>>>         __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
>>> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */
>> Try adding:
>>
>> if (reload > 0xffff)
>> 	reload = 0xffff;
>>
>> before the raw_writel
> No effect. It may make sense but does not fix this bug.

It may also happen that the timer has a lower limit, when the reload
parameter is below this limit, you shoud call ipipe_trigger_irq, as
explained in the porting guide.


-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 08:42 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
>> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
>>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>>>> May it be caused by the following code from plat-samsung/time.c ?
>>>>
>>>> static inline void set_dec(unsigned long reload)
>>>> {
>>>>         __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
>>>> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */
>>> Try adding:
>>>
>>> if (reload > 0xffff)
>>> 	reload = 0xffff;
>>>
>>> before the raw_writel
>> No effect. It may make sense but does not fix this bug.
> It may also happen that the timer has a lower limit, when the reload
> parameter is below this limit, you shoud call ipipe_trigger_irq, as
> explained in the porting guide.
Seems to be not the case but tried it anyway (guessed lower limit
0x00ff), no effect. Also tried to add printk to __ipipe_mach_set_dec,
got the following:

I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
ipipe_mach_set_dec: 42187
ipipe_mach_set_dec: 4294967295
- - (repeats many times) - -
ipipe_mach_set_dec: 4294967295
ipipe_mach_set_dec: 42186
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
ipipe_mach_set_dec: 42187
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)
- - (hangs) - -

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/05/2011 05:23 PM, Alexey Galakhov wrote:
> On 05/05/2011 08:42 PM, Gilles Chanteperdrix wrote:
>> On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
>>> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
>>>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>>>>> May it be caused by the following code from plat-samsung/time.c ?
>>>>>
>>>>> static inline void set_dec(unsigned long reload)
>>>>> {
>>>>>         __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact,
>>>>> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */
>>>> Try adding:
>>>>
>>>> if (reload > 0xffff)
>>>> 	reload = 0xffff;
>>>>
>>>> before the raw_writel
>>> No effect. It may make sense but does not fix this bug.
>> It may also happen that the timer has a lower limit, when the reload
>> parameter is below this limit, you shoud call ipipe_trigger_irq, as
>> explained in the porting guide.
> Seems to be not the case but tried it anyway (guessed lower limit
> 0x00ff), no effect. Also tried to add printk to __ipipe_mach_set_dec,
> got the following:

This is probably the same issue as I had on AT91. Please try disabling
the NO_HZ configuration option.

-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote:
> Please try and move the cal to ipipe_tsc_update to the acktimer function.
> Also call printk in the actkimer function, in order to see if the last
> action is a set_dec, or an acktimer.
Just tried to add printk (not moved anything). Got:

ipipe_mach_set_dec: 4294967295
ipipe_mach_set_dec: 4294967295
ipipe_mach_set_dec: 42186
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
acktimer
acktimer
acktimer
acktimer
acktimer
Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
ipipe_mach_set_dec: 42187
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
acktimer
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote:
> Please try and move the cal to ipipe_tsc_update to the acktimer function.
> Also call printk in the actkimer function, in order to see if the last
> action is a set_dec, or an acktimer.
Tried to move the call. Got exactly the same hangup and dmesg.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/06/2011 11:28 AM, Alexey Galakhov wrote:
> On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote:
>> Please try and move the cal to ipipe_tsc_update to the acktimer function.
>> Also call printk in the actkimer function, in order to see if the last
>> action is a set_dec, or an acktimer.
> Just tried to add printk (not moved anything). Got:
> 
> ipipe_mach_set_dec: 4294967295
> ipipe_mach_set_dec: 4294967295
> ipipe_mach_set_dec: 42186
> Xenomai: scheduling class idle registered.
> Xenomai: scheduling class rt registered.
> acktimer
> acktimer
> acktimer
> acktimer
> acktimer
> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
> ipipe_mach_set_dec: 42187
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> acktimer
> msgmni has been set to 119
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered (default)

Ok, so there is a timer interrupt which does not result in reprogramming
the timer, all you need to find out is why... Could you print the tsc
value for each of these printks?
Also, have you tried putting the call to the tsc update function in the
acktimer function?

-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/06/2011 11:28 AM, Alexey Galakhov wrote:
> On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote:
>> Please try and move the cal to ipipe_tsc_update to the acktimer function.
>> Also call printk in the actkimer function, in order to see if the last
>> action is a set_dec, or an acktimer.
> Just tried to add printk (not moved anything). Got:

Just explaining what happens.

> 
> ipipe_mach_set_dec: 4294967295
> ipipe_mach_set_dec: 4294967295

These are for the setup calibration (rthal_calibrate_timer).

> ipipe_mach_set_dec: 42186

This is the call to __ipipe_mach_release_timer, at the end of
calibration, which should put the timer back under Linux control, in
auto-reload mode.

> Xenomai: scheduling class idle registered.
> Xenomai: scheduling class rt registered.
> acktimer
> acktimer
> acktimer
> acktimer
> acktimer

Linux ticks, set_dec is not called, because the timer auto-reloads.

> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
> ipipe_mach_set_dec: 42187

Here the timer goes under Xenomai control, ipipe_mach_timerstolen is set
to 1.

> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> acktimer

First timer interrupt, should trig a call to Xenomai tick timer handler,
which should reprogram the next timer. At this time, there is only one
timer in Xenomai's list: the host timer, so, we should see an
set_dec(42186) again.

The problem probably comes from the fact that you are running with
CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different
hardware.

-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/06/2011 03:55 PM, Gilles Chanteperdrix wrote:
> The problem probably comes from the fact that you are running with
> CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different
> hardware.
Today I found that the problem is reproduceable on an emulator. There is
a fork of qemu that emulates mini2440 board, it is here:
http://repo.or.cz/w/qemu/mini2440.git . Now I test on the emulator first
as it is faster and does not wear out board's flash.

It is a bit hacked, i.e. you have to have a bootloader in
./mini2440/u-boot.bin and so on but it is quite usable.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/06/2011 03:55 PM, Gilles Chanteperdrix wrote:
> The problem probably comes from the fact that you are running with
> CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different
> hardware.
Looks like S3C2440 is one of the few systems that have
GENERIC_CLOCKEVENTS off (see Kconfig). Other systems seem to turn it on.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote:
> Ok, so there is a timer interrupt which does not result in reprogramming
> the timer, all you need to find out is why... Could you print the tsc
> value for each of these printks?
> Also, have you tried putting the call to the tsc update function in the
> acktimer function?
I did some more investigations and found what actually happens. The call
to xntimer_next_local_shot does not result in a call to
rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean
empty queue?

Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
rthal_timer_request[non-generic]
go
rthal_irq_request 30
ipipe_virtualize_irq 30 c0066bcc
rthal_timer_set_oneshot 1
_mach_set_dec 42187 3035818
_tsc_update
xenomai- steal_timer 1
xntimer_next_local_shot
xnarch_program_timer_shot 0
rthal_timer_program_shot 0
xntimer_tick_aperiodic
xntimer_next_local_shot
- return xntimerq_it_begin == NULL
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
_mach_acktimer 0
xntimer_tick_aperiodic
xntimer_next_local_shot
- return xntimerq_it_begin == NULL
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/11/2011 12:29 PM, Alexey Galakhov wrote:
> On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote:
>> Ok, so there is a timer interrupt which does not result in reprogramming
>> the timer, all you need to find out is why... Could you print the tsc
>> value for each of these printks?
>> Also, have you tried putting the call to the tsc update function in the
>> acktimer function?
> I did some more investigations and found what actually happens. The call
> to xntimer_next_local_shot does not result in a call to
> rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean
> empty queue?
> 
> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
> rthal_timer_request[non-generic]
> go
> rthal_irq_request 30
> ipipe_virtualize_irq 30 c0066bcc
> rthal_timer_set_oneshot 1
> _mach_set_dec 42187 3035818
> _tsc_update
> xenomai- steal_timer 1
> xntimer_next_local_shot
> xnarch_program_timer_shot 0
> rthal_timer_program_shot 0
> xntimer_tick_aperiodic
> xntimer_next_local_shot
> - return xntimerq_it_begin == NULL
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> _mach_acktimer 0
> xntimer_tick_aperiodic
> xntimer_next_local_shot
> - return xntimerq_it_begin == NULL
> msgmni has been set to 119
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered (default)

I was going to check this real soon (tonight probably). At this point
the only timer which should be in the list is the host timer. From
memory, the host timer is or was installed in ksrc/nucleus/timer.c or
ksrc/nucleus/pod.c depending on the return value of rthal_timer_request.
rthal_timer_request implementation depends on CONFIG_GENERIC_CLOCKEVENTS.

So, since we have not checked for some time the code in the case where
this option is disabled, rthal_timer_request return value is probably
now interpreted as meaning that we do not need a host timer, whereas we
need one.

This is my hypothesis at least, but I need to check exactly what happens.

-- 
                                                                Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/11/2011 12:50 PM, Gilles Chanteperdrix wrote:
> On 05/11/2011 12:29 PM, Alexey Galakhov wrote:
>> On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote:
>>> Ok, so there is a timer interrupt which does not result in reprogramming
>>> the timer, all you need to find out is why... Could you print the tsc
>>> value for each of these printks?
>>> Also, have you tried putting the call to the tsc update function in the
>>> acktimer function?
>> I did some more investigations and found what actually happens. The call
>> to xntimer_next_local_shot does not result in a call to
>> rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean
>> empty queue?
>>
>> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
>> rthal_timer_request[non-generic]
>> go
>> rthal_irq_request 30
>> ipipe_virtualize_irq 30 c0066bcc
>> rthal_timer_set_oneshot 1
>> _mach_set_dec 42187 3035818
>> _tsc_update
>> xenomai- steal_timer 1
>> xntimer_next_local_shot
>> xnarch_program_timer_shot 0
>> rthal_timer_program_shot 0
>> xntimer_tick_aperiodic
>> xntimer_next_local_shot
>> - return xntimerq_it_begin == NULL
>> Xenomai: starting native API services.
>> Xenomai: starting POSIX services.
>> Xenomai: starting RTDM services.
>> _mach_acktimer 0
>> xntimer_tick_aperiodic
>> xntimer_next_local_shot
>> - return xntimerq_it_begin == NULL
>> msgmni has been set to 119
>> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
>> io scheduler noop registered (default)
> 
> I was going to check this real soon (tonight probably). At this point
> the only timer which should be in the list is the host timer. From
> memory, the host timer is or was installed in ksrc/nucleus/timer.c or
> ksrc/nucleus/pod.c depending on the return value of rthal_timer_request.
> rthal_timer_request implementation depends on CONFIG_GENERIC_CLOCKEVENTS.
> 
> So, since we have not checked for some time the code in the case where
> this option is disabled, rthal_timer_request return value is probably
> now interpreted as meaning that we do not need a host timer, whereas we
> need one.
> 
> This is my hypothesis at least, but I need to check exactly what happens.
> 

Try this:
diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c
index 2ca0d6c..534f97f 100644
--- a/ksrc/arch/arm/hal.c
+++ b/ksrc/arch/arm/hal.c
@@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu)
 
 	rthal_timer_set_oneshot(1);
 
-	return 0;
+	return 1000000000UL / HZ;
 }
 
 void rthal_timer_release(int cpu)


-- 
					    Gilles.

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Alexey Galakhov]

On 05/11/2011 06:24 PM, Gilles Chanteperdrix wrote:
> Try this:
> diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c
> index 2ca0d6c..534f97f 100644
> --- a/ksrc/arch/arm/hal.c
> +++ b/ksrc/arch/arm/hal.c
> @@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu)
>  
>  	rthal_timer_set_oneshot(1);
>  
> -	return 0;
> +	return 1000000000UL / HZ;
>  }
Seems to be fixed, thanks!

I just compared generic and non-generic rthal_timer_request and already
tried "return 1" but did not realized that "1G/Hz" is correct return value.

--
Alex

Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init

[Gilles Chanteperdrix]

On 05/11/2011 02:35 PM, Alexey Galakhov wrote:
> On 05/11/2011 06:24 PM, Gilles Chanteperdrix wrote:
>> Try this:
>> diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c
>> index 2ca0d6c..534f97f 100644
>> --- a/ksrc/arch/arm/hal.c
>> +++ b/ksrc/arch/arm/hal.c
>> @@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu)
>>  
>>  	rthal_timer_set_oneshot(1);
>>  
>> -	return 0;
>> +	return 1000000000UL / HZ;
>>  }
> Seems to be fixed, thanks!
> 
> I just compared generic and non-generic rthal_timer_request and already
> tried "return 1" but did not realized that "1G/Hz" is correct return value.

That is good news, all the Xenomai and I-pipe patches were merged.

-- 
                                                                Gilles.