Jeroen Van den Keybus wrote: > We have a driver that operates on a PCIe card. The card has IRQ17. If we > use it like that (IO-APIC-fasteoi), interrupt registration using > rtdm_irq_request works correctly. (We also use rtdm_irq_enable > afterwards, but it seems that the request already enables the interrupt.) >
Yes, it does. > However, if we redefine our interrupt as MSI using pci_enable_msi(), > rtdm_irq_request freezes the machine. (After pci_enable_msi, the new > interrupt vector is 218 and /proc/interrupts correctly reports > PCI-MSI-edge.) > > We have another MSI-enabled card in the system (network card controlled > by Linux) and this one works correctly. So I suspect that the Ipipe is > clear and the bug must reside in Xenomai. > > I've been adding printk instrumentation throughout the Ipipe, Xenomai > and RTDM, but the problem is that possibly the contents of the kernel > log do not make it to the terminal upon the freeze (no oops, no panic). > Is there any way of efficiently debugging this ? > First, you may want to try commenting out the call to xnintr_irq_enable() from rtdm_irq_request() - and your own call if any - to check whether the system remains functional without enabling the IRQ line. If so, then this may be an acknowledge issue. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
