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?
HTH::Bernhard
-------------------------------------------------------------------------
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
