From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 14 Jul 2015 00:39:32 +0200 From: Gilles Chanteperdrix Message-ID: <20150713223932.GA1971@hermes.click-hack.org> References: <55A3EE26.5070802@sigmatek.at> <7413ead94cb8c4f3a91d1288a27103c9.squirrel@sourcetrek.com> <55A3F4B3.1090908@sigmatek.at> <20150713195856.GA1552@hermes.click-hack.org> <55A41E26.9020903@sigmatek.at> <20150713203133.GA2022@hermes.click-hack.org> <55A4235D.2000601@sigmatek.at> <20150713205412.GC2022@hermes.click-hack.org> <55A4346B.9030309@sigmatek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A4346B.9030309@sigmatek.at> Subject: Re: [Xenomai] usage of rtdm_task_sleep_abs List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johann Obermayr Cc: xenomai@xenomai.org 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 > Xenomai@xenomai.org > http://xenomai.org/mailman/listinfo/xenomai -- Gilles. https://click-hack.org