Re: [Xenomai-core] Handling PCI MSI interrupts

[Philippe Gerum <rpm@xenomai.org>]

Jeroen Van den Keybus wrote:
>     I tried this patch and it doesn't solve the issue I'm facing. With and
>     without this patch, my symptoms are the same. 
> 
> 
> I tested (and intended) the patch for MSI (w/o maskbits), not MSI-X. 
> What e1000 chip are you using exactly? Easiest way to tell is by using 
> '/sbin/lspci'. I may be able to help you out with MSI-X as well, but in 
> that case, I have no hardware platform to test on.
>

Could you post the patch you are successfully using to boot your box? TIA,

> You can check whether or not MSI is actually being used by doing 
> '/sbin/lspci -v' and look for the Capability: Message Signalled 
> Interrupt. When the driver is running in MSI mode, it should read 
> 'Enable+' instead of 'Enable-'.
> 
> Finally, verify how interrupts are dispatched. Have a look at 
> /proc/interrupts for this (cat /proc/interrupts').
> 
>     I'm running a Dell 2850, dual CPU machine.
> 
> 
> As it's a Dell, I assume there's two Intel Penium CPU's inside. Are you 
> running with SMP enabled ?
> 
>       When I build a kernel without
>     Adeos then things are fine.  When I build with Adeos and MSI enabled
>     the
>     following occurs:
> 
>     1) If BIOS has USB disabled then the system will hang without even a
>     num-lock respose (i.e. tapping the num-lock key doesn't toggle the
>     light).
>     The hang occurs just about the time the E1000 driver would load and
>     enable
>     an MSI interrupt.
> 
>     2) If BIOS has USB enabled then the system will run much longer but
>     may hang
>     during heavy interrupt load on the E1000 driver.
> 
> 
> Are you using the e1000 driver in NAPI mode ? It is recommended to do 
> this, especially on the preemptible kernel, as it may significantly 
> reduce the interrupt volume. In that case, I think it is doubtful if 
> using MSI would give you any benefit at all over normal, shared IRQs.
> 
>     My assumption based on past experience is that no num-lock response
>     means an
>     infinite interrupt loop. 
> 
> 
> The local (internal) CPU APIC hasn't been informed that the interrupt 
> has been dealt with and it will therefore allow no other interrupts 
> anymore to arrive in the CPU (including your keyboard's). In fact, your 
> CPU is idle.
> 
> [The original 8259 was designed to detect the IRET instruction bit 
> pattern on the databus and use that as an acknowledge signal. Upon 
> arrival of the second 8259 in the PC/AT, this could no longer be done. I 
> don't know if the APIC could do it today (it seems possible, 
> theoretically). ]
>  
> When I build a kernel with Adeos but disable MSI then the system works fine
> 
>     for the most part.  There is one scenario where the system will
>     still hang
>     doing disk and network accesses under a moderate load of I/O. 
> 
> 
> Hm. That may indicate another issue.

Indeed. This behaviour has not been reported yet with patches from the Adeos 
I-pipe series. Does it also happen with SMP disabled, or Hyperthreading disabled?

> 
>     Both of these tests are just to get a stable kernel before I really
>     start
>     using Adeos.  So Adeos is in its default configuration and I haven't
>     loaded
>     Xenomai modules when these hangs occur.
> 
>     I'm currently running the 2.6.14.4 <http://2.6.14.4> kernel with the
>     2.6.14-1.0-12 patch of
>     adeos and then I included your msi.c patch from the previous
>     e-mail.  If you
>     have any further hints or suggestions I'll try them.  Meanwhile I'm
>     trying
>     different versions of various drivers (e1000 and scsi) as well as
>     updating
>     the patch level of the kernel itself.
> 
> 
> Try upgrading the kernel. The kernel usually comes with updated drivers 
> as well. Currently I'm running 2.6.16-rc2, which I had to patch manually 
> for Adeos (about 3 'hunks' from the 2.6.15-i386-1.2-00 patch didn't 
> apply properly). By using 2.6.16-rc2, I got much better Intel 
> (especially i865 graphics) chipset support than 2.6.15. Note, however, 
> that I did the bug fixing in this thread on a plain 2.6.15, though (and 
> the msi.c code is nearly identical).
> 
> I would recommend upgrading to 2.6.15 with the latest Adeos patch and 
> try to get a stable system before enabling MSI.
> 
> Jeroen.
> 


-- 

Philippe.