INTR-REMAP error with UDD driver
w1 at codecraftsmen.org
Fri Mar 8 15:07:26 CET 2019
On Friday, March 8, 2019 1:14 AM, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> On 08.03.19 02:35, Jeff Webb via Xenomai wrote:
> > I have implemented a simple UDD mini-driver (interrupt handler) and an associated Xenomai userspace test program. This pair of programs works as intended on one machine. When I tried running the same programs on another machine, I got this error when the first interrupt occurred:
> > kernel: [ 75.122305] DMAR: DRHD: handling fault status reg 2
> > kernel: [ 75.123175] DMAR: [INTR-REMAP] Request device [f0:1f.0] fault index ee00 [fault reason 37] Blocked a compatibility format interrupt request
> This means the device is under IOMMU interrupt remapping regime, but it was
> programmed to use a standard MSI/MSI-X request, rather than requesting that
> parameters (address/data tuple) from the Linux interrupt management layer that
> will assign a remapping slot and hand out the right values. Now you interrupt is
> stuck in the filter.
> Before suggesting the workaround/hack to disable interrupt remapping: How did
> you program MSI/-X? Via proper Linux pci_* helpers?
The PCI card I am working with does not implement MSI interrupts, but just uses the legacy interrupt pin A. It's confusing to me that this error is associated with MSI. Since this behavior is slot-dependent, I figured at first that the error is from another device on the same interrupt line, but I get the same error on several different slots. There is only one slot where things work as expected.
Thanks for the response,
> > I would guess that the [f0:1f.0] in the message is a PCI bus address, but I don't see this via lspci. The closest match is:
> > 00:1f.0 ISA bridge : Intel Corporation Q67 Express Chipset LPC Controller [8086:1c4e] (rev 05)
> > After the first attempt, I see no more of these messages until I reboot, but the UDD driver never receives an interrupt in any case.
> > I tried moving my PCI card to five different slots, and finally found one where everything work properly on the second machine. I can at continue to make progress using the working slot, but I would really like to resolve the issue with the other slots. Does anyone have any idea what to try next?
> > I am using these sources:
> > linux-4.14.89.tar
> > ipipe-core-4.14.89-x86-2.patch
> > xenomai-3.0.8.tar
> > I have attached the boot log, config, and cpu information.
> > Thanks,
> > -Jeff Webb
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
More information about the Xenomai