Re: [Xenomai] usage of rtdm_task_sleep_abs

[Johann Obermayr <johann.obermayr@sigmatek.at>]

Am 16.07.2015 um 08:30 schrieb Gilles Chanteperdrix:
> On Wed, Jul 15, 2015 at 11:00:55PM +0200, Johann Obermayr wrote:
>> Am 14.07.2015 um 02:02 schrieb Gilles Chanteperdrix:
>>> On Tue, Jul 14, 2015 at 01:30:59AM +0200, Johann Obermayr wrote:
>>>> Am 14.07.2015 um 00:39 schrieb Gilles Chanteperdrix:
>>>>> You mean there is an issue with bus contention? Are there many
>>>>> things occupying the bus when the problem happens?
>>>> Hi,
>>>>
>>>> both cpu core can access our pci-card.
>>>>
>>>> at this time we only have one pci-card with an fpga(with dpram) and a sram.
>>>> the fpga generate our system tick. And have a company internal bus system.
>>>> this bus system can configured with the dpram & fpga-config register.
>>>> we also must read witch irq come from the fpga, because internal he can have
>>>> more than one irq sources. and we must quit this irq. (with reading a fpga
>>>> register)
>>>>
>>>> we see that if one core accessing the pci-bus, the other core have a high
>>>> latency.
>>>> core0 = importan & high prior accessing fpga and sram
>>>> core1 = linux & visu & some other low prior
>>>>
>>>> if a low prior copy a memblock to/from the sram, the core0 have high latency
>>>> in
>>>> our irq handler at reading some data from fpga.
>>>> so we add a own pci-blocker task on core1. this task ist started about 50us
>>>> before
>>>> next tick-irq is coming. now our irq handle can access the fpga without
>>>> waiting.
>>> Well, normally, a PCI bus controller has parameters controlling the
>>> duration of the longest burst, adequately named "PCI latency". You
>>> should also look at whether caching is enabled. A PCI bridge will
>>> normally prefetch from a PCI bar (provided that the FPGA indicates
>>> in the configuration bytes that the memory is prefetchable) to avoid
>>> CPU wait states. Using what was once called MTRR, but has a new name
>>> in new processor, you can cause the procesdor to buffer data before
>>> sending large bursts on the PCI bus. I think what you need to have a
>>> look at is the documentation of the PCIe to PCI bridge, to see if
>>> you can not improve the situation by better configuring it. Also,
>>> reading or writing to FPGA is RAM looks pretty strange, since I
>>> would guess an FPGA could be master on the PCI bus and do DMA
>>> itself, thereby relieving the CPU.
>>>
>> Hello,
>>
>> how can i check, if the TSC on both core are run syncron ?
>> Dual Core Celeron, no Hyperthreading.
> Quite frankly, I think it is pretty clear what the problem is now:
> you are accessing your SRAM in uncached mode, which causes large
> wait states in your processor and cause it to misbehave somehow. Try
> to fix that, enable pre-fetching on the PCI bridge as well, I
> believe everything else are red herrings.
>
> Regards.
>
Hello,

this is our PCI-card

02:04.0 ACCESS Bus: Device 5112:2200
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium 
 >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 32
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at f6800000 (32-bit, non-prefetchable) FPGA & SRAM
         Region 1: Memory at f7000000 (32-bit, non-prefetchable) DPRAM
         Kernel driver in use: Sigmatek PCI

SRAM is a part of the FPGA space. for FPGA we must use non-prefetchable.
i will talk , if there is a way to add a own region for SRAM, that is 
prefetchable.
for the bridge chip, i does not found about prefetchable.

Why can sometime Core1 SRAM access not interrupted by the timer/schedule ?