Bernhard Pfund wrote:
> Philippe Gerum wrote:
>> [EMAIL PROTECTED] wrote:
>>> Zitat von Philippe Gerum <[EMAIL PROTECTED]>:
>>>
>>>> Bernhard Pfund wrote:
>>>>> Philippe Gerum wrote:
>>>>>> Bernhard Pfund wrote:
>>>>>>>> I see no option aside of ironing the inner code that reads/writes the
>>>>>>>> PCI
>>>>>>>> config, so here is an ugly yet possible solution for x86, that might
>>>>>>>> work
>>>>>>>> (totally untested):
>>>>>>>>
>>>>>>>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>>>>>>>> index 6e64aaf..7f32101 100644
>>>>>>>> --- a/arch/x86/pci/common.c
>>>>>>>> +++ b/arch/x86/pci/common.c
>>>>>>>> @@ -75,7 +75,7 @@ int pcibios_scanned;
>>>>>>>> * This interrupt-safe spinlock protects all accesses to PCI
>>>>>>>> * configuration space.
>>>>>>>> */
>>>>>>>> -DEFINE_SPINLOCK(pci_config_lock);
>>>>>>>> +IPIPE_DEFINE_SPINLOCK(pci_config_lock);
>>>>>>>>
>>>>>>>> static int __devinit can_skip_ioresource_align(const struct
>>>>>>>> dmi_system_id *d)
>>>>>>>> {
>>>>>>>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>>>>>>>> index 39bb96b..9a74083 100644
>>>>>>>> --- a/drivers/pci/access.c
>>>>>>>> +++ b/drivers/pci/access.c
>>>>>>>> @@ -12,7 +12,7 @@
>>>>>>>> * configuration space.
>>>>>>>> */
>>>>>>>>
>>>>>>>> -static DEFINE_SPINLOCK(pci_lock);
>>>>>>>> +static IPIPE_DEFINE_SPINLOCK(pci_lock);
>>>>>>>>
>>>>>>>> /*
>>>>>>>> * Wrappers for all PCI configuration access functions. They
>>>>>>>> just check
>>>>>>>>
>>>>>>> This results in:
>>>>>>>
>>>>>>> arch/x86/pci/common.c:78: error: conflicting types for ‘pci_config_lock’
>>>>>>> arch/x86/pci/pci.h:84: error: previous declaration of ‘pci_config_lock’
>>>>>>> was here
>>>>>>>
>>>>>>> Didn't look into it, just tried ;)
>>>>>>>
>>>>>> Just change the declaration in pci.h the same way.
>>>>>>
>>>>> Ok, thanx! Seems to work for now, no extensive testing done (yet)
>>>>> though. What's the plan for the future? Will this change find its way
>>>>> into the official patch?
>>>>>
>>>> This change could be merged into the 2.6.26 patch provided it does
>>>> not raise any
>>>> pathological latency when enabling MSI. I would rather ask people to
>>>> refrain
>>>> from using MSI until it is fixed (once again) in later releases,
>>>> than suffering
>>>> random latency peaks. 2.6.27 and beyond is another issue; this will need a
>>>> different approach than simply ironing the PCI lock in any case.
>>>>
>>>> We need more test data for 2.6.26 + this patch.
>>>>
>>> Let me know if I can be of any help. I'm in an early stage of the
>>> project, so there's some time available for MSI experiments...
>>>
>> Thanks. Basically, we need to know the impact of this patch under high load
>> for
>> at least four hours runtime, with significant interrupt traffic to/from MSI
>> devices in parallel.
>>
>
> Hmm, I think I actually have a setup that could do the trick. One GBit
> NIC under control of RTnet and another in the Linux domain, both PCIe
> devices. MSIs are enabled in the kernel (2.6.26.2), without MSI they
> would share the same IRQ.
>
> I could connect them to the same physical network and ping flood both
> cards from a second system, for 24h if necessary.
>
> How would you measure the effect of the patch?
>
The risk in ironing those PCI locks is to run with hw interrupts disabled for a
long time, inducing pathological latencies, so running RTAI's latency test in
the background should help detecting those peaks.
However, we may find nothing bad if the kernel uses the MMConfig access method
to the PCI space since this is basically fast mmio there. But since you seem to
be running on x86_32, we may want to check whether BIOS or direct access to the
PCI config does not raise the typical latency too much, as well (I'm unsure that
PCI_GOBIOS will give us decent results though).
To sum up: with different settings for the PCI config access method in "Bus
options" (by order of criticality, MMConfig then Direct, then maybe BIOS), does
the latency tool report pathological peaks?
TIA,
> HTH::Bernhard
>
> _______________________________________________
> Adeos-main mailing list
> [EMAIL PROTECTED]
> https://mail.gna.org/listinfo/adeos-main
--
Philippe.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
