INTR-REMAP error with UDD driver

Jim Elliott jim.elliott at nta-inc.net
Thu Mar 28 18:10:24 CET 2019


Hey guys, I was wondering if there is an update on the INTR-REMAP UDD driver issue.  We have not had any troubleshooting breakthroughs on our end.


Best Regards,

Jim Elliott

________________________________
From: Xenomai <xenomai-bounces at xenomai.org> on behalf of Jeff Webb via Xenomai <xenomai at xenomai.org>
Sent: Friday, March 8, 2019 8:07 AM
To: Jan Kiszka
Cc: xenomai at xenomai.org
Subject: Re: INTR-REMAP error with UDD driver

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,

-Jeff

>
> Jan
>
> > 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 [0601]: 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




________________________________

CONFIDENTIALITY NOTICE: The contents of this e-mail message may be privileged, confidential, proprietary, Controlled Unclassified Information (CUI) or otherwise protected against disclosure or dissemination. This e-mail message and any files transmitted with it are intended solely for the use of the individual/individuals or entity/entities to whom they are addressed. If you are not the intended recipient of this message, any dissemination, distribution, printing or copying is strictly prohibited. If you have received this message in error, please e-mail or call the sender (jim.elliott at nta-inc.net, ) and destroy all copies.



More information about the Xenomai mailing list