Re: [Adeos-main] [RTnet-users] e1000 & MSI

[Philippe Gerum <rpm@xenomai.org>]

bernhard@domain.hid wrote:
> Zitat von Philippe Gerum <rpm@xenomai.org>:
> 
>> 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?
>>
> 
> Hi Philippe
> 
> I played with the different PCI configurations and the results are  
> devastating. Latencies (and jitter) skyrocket after some minutes of  
> testing and peak at several milliseconds. I didn't do the regression  
> with 'normal' INTs though, but that's something up next. Additionally  
> MMCONFIG produced some strange msg at boot.
> 
> I suspect I'm going to use INTs for my current project :(
> 
> Bernhard
> 
> 
> PCI_GOMMCONFIG
> --------------
> 
> I get the following dmesg:
> 
> ACPI: bus type pci registered
> PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 31
> PCI: Not using MMCONFIG.
> PCI: Fatal: No config space access function found

Your hw does not seem to have PCI Express support, hence MMConfig access method
is not available. The kernel is expected to downgrade to direct access method.

> [....]
> 
> 
> PCI_GODIRECT
> ------------
> 
> Here desg looks better:
> 
> ACPI: bus type pci registered
> PCI: Using configuration type 1 for base access

Direct access type 1 is done through in/out{b, w, l} commands, which is not
cheap. Well, if it proves that we don't face any unknown issue with direct
access, only getting virtualized masking/unmasking of MSI driven interrupts
would save the day.

-- 
Philippe.