Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

M. Koehrer wrote:
> Hi everybody,
> 
> I have been gone one step back to analyze the issue from the situation is originally occurred.
> This was the situation that I had a 2.6.20.4 kernel and Xenomai 2.3.1 (included Adeos patch).
> When I  enable MSI in the kernel configuration I get the kernel message:
> "spurious APIC interrupt on CPU#0, should never happen."
> when trying to enable (ifconfig) the e1000 driver for an onboard PCIe network adapter.
> 
> I have now used the very same kernel without Xenomai patch, but using the same kernel config
> (MSI enabled). This returns the IRQ 223 for the Ethernet adapter.
> With 2.6.21 it returns IRQ 219, there seems to be a difference between 2.6.20 and 2.6.21.
> Well, as I am working with 2.6.20.4, I looked deeper in that.
> 
> One interesting thing I found was in arch/i386/kernel/ipipe.c at function __ipipe_enable_pipeline
> I do not understand the meaning of that code.
> At the beginning of that function, there are a couple of calls to ipipe_virtualize_irq().
> These MAP the APIC system vectors.
> However, the second call that maps 
> SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR (with is infact 223) is mapped to
> smp_spurious_interrupt (which leads to the result I see).
> However, I am not sure if it is correct to use the VECTOR values here as ipipe_virtualize_irq
> uses "irq" as second parameter and not  a vector. This looks like a vector vs. irq mismatch.

Isn't this the issue Philippe's last patch against ipipe and xenomai fixes?

> 
> Within the create_irq() function, the e1000 creates irq 223 on vector 201.
> 
> When I monitor the calls to set_intr_gate() I see that the vector 32 will end up at the address
> of irq_entries_start, vector 32 will end up at irq_entries_start + 8 etc.
> In entry.S this will end up in writing ~(vector) unto the stack and calling common_interrupt.
> This finally calls __ipipe_handle_irq.
> The means that __ipipe_handle_irq will not be called with the IRQ number but with the vector!!
> It could be that this is the same for the "old" IRQ vectors (<32). 
> However for the MSI IRQs this seems to be not correct.
> I think that this could be the root cause for the problems I see.

Again, please verify that you are not debugging the issue that Philippe
may have already fixed, ie. re-evaluate your (very systematic!) findings
after applying the ipipe fix.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]