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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
