----- Den 28 mar 2019, på kl 18:10, xenomai xenomai@xenomai.org skrev:
> 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. When I read this I realize I have a similar or the same issue. When I moved from 4.9.38 to 4.9.90 the xenomai_peak_pci driver stopped getting interrupts and I got a note about io-remapping and a blocked compability interrupt. It worked on another motherboard. The kernel-configs were not equal, and I haven't had time to troubleshoot this. When I switched to the new Peak driver it worked so I focused on other things instead. I may be able to contribute in the future. Best regards Per Öberg > 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.
