INTR-REMAP error with UDD driver

Jan Kiszka jan.kiszka at siemens.com
Fri Mar 8 16:00:52 CET 2019


On 08.03.19 15:07, Jeff Webb wrote:
> 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.
> 

Ok, then we may have an issue with how we register legacy INTx at the IOAPIC 
when interrupt remapping is on. Basically, the IOAPIC sends MSI-like messages as 
well that are subject to remapping. So its registers need to be programmed with 
the right translatable values, just like the MSI registers of a device. Linux 
does that, it's in charge of the IOMMU. I don't recall how we (Xenomai/I-pipe) 
fill the IOAPIC if a line was not used before under Linux. Possibly, there is 
the wrong Linux function triggered. But maybe it's also something different.

I assume you tested that your card would work find if it used only regular Linux 
driver services, no RTDM, right? That would be good in order to exclude a 
general platform issue, maybe a BIOS (ACPI) bug in describing which PCI slot is 
under which IOMMU regime.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list