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-boun...@xenomai.org> on behalf of Jeff Webb via Xenomai <xenomai@xenomai.org> Sent: Friday, March 8, 2019 8:07 AM To: Jan Kiszka Cc: xenomai@xenomai.org Subject: Re: INTR-REMAP error with UDD driver On Friday, March 8, 2019 1:14 AM, Jan Kiszka <jan.kis...@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.elli...@nta-inc.net, ) and destroy all copies.
