On Mon, Jul 13, 2015 at 11:58:03PM +0200, Johann Obermayr wrote:
> Am 13.07.2015 um 22:54 schrieb Gilles Chanteperdrix:
> >On Mon, Jul 13, 2015 at 10:45:17PM +0200, Johann Obermayr wrote:
> >>Am 13.07.2015 um 22:31 schrieb Gilles Chanteperdrix:
> >>>On Mon, Jul 13, 2015 at 10:23:02PM +0200, Johann Obermayr wrote:
> >>>>Am 13.07.2015 um 21:58 schrieb Gilles Chanteperdrix:
> >>>>>On Mon, Jul 13, 2015 at 07:26:11PM +0200, Johann Obermayr wrote:
> >>>>>>Am 13.07.2015 um 19:21 schrieb Gilles Chanteperdrix:
> >>>>>>>Johann Obermayr wrote:
> >>>>>>>>Am 13.07.2015 um 17:24 schrieb Gilles Chanteperdrix:
> >>>>>>>>>Johann Obermayr wrote:
> >>>>>>>>>>without your application, there are no large latencies.
> >>>>>>>>>>with your application see frozen.txt (with latency -f)
> >>>>>>>>>I am confused. You mean "our application", not "your application",
> >>>>>>>>>right?
> >>>>>>>>>lrtdrv_monitoring_irq is not part of the code delivered by the
> >>>>>>>>>Xenomai
> >>>>>>>>>project.
> >>>>>>>>>
> >>>>>>>>>>We see the problem only if one task (background) is accessing the
> >>>>>>>>>>SRAM
> >>>>>>>>>>on your PCI-Card. if we stop this task, all is ok.
> >>>>>>>>>Again: the Xenomai project does not make PCI-card. So, you probably
> >>>>>>>>>mean
> >>>>>>>>>"our PCI-Card"?
> >>>>>>>>yes, our PCI-Card. (sorry for my bad english)
> >>>>>>>>>>So we have a higher prior task (pci-locker), that interrupt the
> >>>>>>>>>>background task, so that the pci bus get free.
> >>>>>>>>>I am not sure I understand your explanations. But the trace is pretty
> >>>>>>>>>clear:
> >>>>>>>>>
> >>>>>>>>>At time -658 the timer is programmed to tick at -561.
> >>>>>>>>>
> >>>>>>>>>>:| # event tick@-561 -658 0.112
> >>>>>>>>>>xntimer_next_local_shot+0xca
> >>>>>>>>>>:| + func -651 0.145
> >>>>>>>>>>lrtdrv_monitoring_irq+0x4
> >>>>>>>>>>[sigmatek_lrt] (irq_hook_handler+0x32 [sigmatek_lrt])
> >>>>>>>>>>:| + end 0x000000ef -651! 641.640 apic_timer_interrupt+0x52
> >>>>>>>>>>(<102d0254>)
> >>>>>>>>>But at that point the tick is delayed for 600us. And according to the
> >>>>>>>>>trace, the last traced function called before that delay is the
> >>>>>>>>>function
> >>>>>>>>>
> >>>>>>>>>ltdrv_monitoring_irq.
> >>>>>>>>>
> >>>>>>>>>So, I do not know what this irq is doing, but I would suggest having
> >>>>>>>>>a
> >>>>>>>>>close look at it.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>hello,
> >>>>>>>>
> >>>>>>>>i have disable our lrtdrv_monitoring_irq.
> >>>>>>>>Only have this callback
> >>>>>>>>static void irq_hook_handler(unsigned int irq, unsigned int state)
> >>>>>>>>{
> >>>>>>>> if (fpga_interrupt == irq && state == 0x01)
> >>>>>>>> {
> >>>>>>>> time_fpga_irq = rt_timer_tsc();
> >>>>>>>> }
> >>>>>>>>}
> >>>>>>>>same latency
> >>>>>>>Maybe, but your trace does not contain enough points to see it. The
> >>>>>>>trace
> >>>>>>>should at least contain the "tick@" event which gets missed, so that we
> >>>>>>>can see how much the interrupt is delayed, and what was happening at
> >>>>>>>the
> >>>>>>>time.
> >>>>>>>
> >>>>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>Sorry, here with more points.
> >>>>>Ok, what is irq_hook_handler ?
> >>>>>
> >>>>Ok. on out PCI Card there is a FPGA. This FPGA generate am Interrupt to
> >>>>the
> >>>>PC. But internal in the FPGA there
> >>>>are different IRQ sources. One of them is our Tick.
> >>>>So we measure the time from __ipipe_handle_irq to the our
> >>>>rtdm_irq_request
> >>>>handler.
> >>>>In our handler we can check, if it our Tick and than we can calc the
> >>>>correct
> >>>>time to start our pci_locker task 50us before next Tick-irq.
> >>>>
> >>>>It's a callback function from some irq function ipipe_raise_irq,
> >>>>__ipipe_do_IRQ, __ipipe_handle_irq
> >>>>for our own tracing and it save the fpga irq time.
> >>>>Only __ipipe_handle_irq have state 0x01 (begin irq) & state 0x02 at the
> >>>>end
> >>>>of the function.
> >>>I see two weird things in your traces:
> >>>- irq_hook_handler which is taking a lot of time
> >>>- or some APIC related functions taking a lot of time.
> >>>
> >>>Are you sure your system is not one of those which disable the APIC
> >>>during idle period. Is your system UP or SMP?
> >>>
> >>It's a SMP (Dual core Celeron)
> >Real dual core, or hyperthreaded ?
> >
> >>Kernel cmdline
> >>nohlt idle=poll xeno_hal.smi=1 isolcpus=0 irqaffinity=1 console=ttyS0,115200
> >>BOOT_IMAGE=/bzImage FirstUsbDrive=E console=/dev/null noconsole
> >>root=/dev/sda2 rw
> >Do you have the same problem without these options ?
> >nohlt idle=poll xeno_hal.smi=1 isolcpus=0 irqaffinity=1
> >
> Hello Gilles,
>
> the trouble are only if our SRAM test on our pci-card is running (on core1).
> we have see, that the the core0 must wait, if he will access the fpga.
> can it be, that the apic has the same trouble ?
You mean there is an issue with bus contention? Are there many
things occupying the bus when the problem happens?
>
> Regards
>
> _______________________________________________
> Xenomai mailing list
> [email protected]
> http://xenomai.org/mailman/listinfo/xenomai
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
