On 23.05.19 07:59, Ralf Ramsauer wrote:
Hi all,
On 5/12/19 9:51 AM, Jan Kiszka wrote:
On 10.05.19 15:11, [email protected] wrote:
Hello everyone,
I'm still trying to get my rootCell running. I have for the moment
connected a serial port in order to have the logs in full (in ssh the
communication was down before I could have the logs). After solving
some minor errors (such as Invalid MMIO/RAM read or IO-port) I find
myself with an error that I can't explain:
VT-d fault event reported by IOMMU 1:
Source Identifier (bus:dev.func): 03:00.0
Fault Reason: 0x22 Fault Info: 38000000000 Type 0
VT-d fault event reported by IOMMU 1:
Source Identifier (bus:dev.func): 03:00.0
Fault Reason: 0x22 Fault Info: 3c000000000 Type 0
VT-d fault event reported by IOMMU 1:
Source Identifier (bus:dev.func): 03:00.0
Fault Reason: 0x22 Fault Info: 39000000000 Type 0
VT-d fault event reported by IOMMU 1:
Source Identifier (bus:dev.func): 03:00.0
Fault Reason: 0x22 Fault Info: 3b000000000 Type 0
hmm, sounds familiar.
On a Dell T440, we have the *exact* same issue with a similar card: a
BCM5720, pretty similar to your BCM5719. See my thread "VT-d: IOMMU
exception with unknown fault reason"). And yes, there we have an active
link on it.
Is the new sysfs-parser.py the cause of my trouble or is there
anything I missed in the configuration ?
Could be. 0x22 means that the device is not present in the interrupt
We have no modifications of the sysfs parser and face the same issue.
remapping
table of IOMMU that is responsible for that device. Try changing the .iommu
number for that device from 0 to 1 or the other way around. Or is there
no entry
for 03:00.0 at all?
Jeanne, were you already able to solve this issue?
I manually parsed (my) DMAR, and there's a ATSR structure (type 0x2)
which is ignored by the config parser. Could this be related to this
issue or can it simply be ignored?
In this system, we have four iommus. Mario, did you already test all
possibilities for .iommu (0, 1, 2, 3)?
If that doesn't help, instrumenting what Jailhouse programs into the interrupt
remapping table for the device in question against what is being reported would
be the next step.
"When the Fault Reason (FR) field indicates one of the interrupt-remapping fault
conditions, bits 63:48 of this field contains the interrupt_index computed for
the faulted interrupt request, and bits 48:12 are cleared."
Maybe, for whatever reasons, Jailhouse does not transfer the remapping table
entry that exists prior to Jailhouse into the table that is formed during enabling.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/3886ba1d-58e1-abb4-27b6-23b09863c6b3%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
