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.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
