Coreboot upgrade video failure (DMAR issues?)

Asmadeus · April 2, 2018, 5:08pm

(off-topic: WTB a “coreboot” label)

Hi folks,

It’s been a while since I last posted here as I had been busy not breaking this shiny laptop, but that couldn’t laste too long

So here we are:

I was/am back to running coreboot 4.6-a86d1b-Purism-5, the laptop is a librem 15 v3.
Upgrading to 4.7 Purism-4 with the build-coreboot.sh script of coreboot-files looked like it works fine, at least as far as the script/building goes, I could build the coreboot image with the right hash without any trouble and it flashed correctly…
Except that once I tried rebooting to it, anything using the GPU failed hard! Basically I had to reboot in single mode with nomodeset to make sure and reflash the old coreboot image from there.

I’ve seen on this forum that others successfully flashed this just fine, so it might be something on my end. So far I only took the time to remove my intel_pstate=disable but I have other options that might affect this (i915.enable_gvt=1 kvm.ignore_msrs=1 intel_iommu=on drm.debug=0), and I didn’t take the time to take any trace… Now I’m looking at journal logs I think it might just be these, but they used to work, so I’d like them to work again eventually as I use intel graphics virtualisation from time to time…
Here’s some DMAR errors:

Apr 03 01:31:10 laptop kernel: ACPI: DMAR 0x000000007AAB3230 000068 (v01 CORE   COREBOOT 00000000 CORE 00000000)
Apr 03 01:31:10 laptop kernel: DMAR: IOMMU enabled
Apr 03 01:31:10 laptop kernel: DMAR: Host address width 39
Apr 03 01:31:10 laptop kernel: DMAR: DRHD base: 0x000000fed90000 flags: 0x0
Apr 03 01:31:10 laptop kernel: DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e3ff0505e
Apr 03 01:31:10 laptop kernel: DMAR: DRHD base: 0x000000fed91000 flags: 0x1
Apr 03 01:31:10 laptop kernel: DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462 ecap f050da
Apr 03 01:31:10 laptop kernel: DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
Apr 03 01:31:10 laptop kernel: DMAR-IR: HPET id 0 under DRHD base 0xfed91000
Apr 03 01:31:10 laptop kernel: DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
Apr 03 01:31:10 laptop kernel: DMAR-IR: Enabled IRQ remapping in x2apic mode
Apr 03 01:31:10 laptop kernel: DMAR: No RMRR found
Apr 03 01:31:10 laptop kernel: DMAR: No ATSR found
Apr 03 01:31:10 laptop kernel: DMAR: dmar0: Using Queued invalidation
Apr 03 01:31:10 laptop kernel: DMAR: dmar1: Using Queued invalidation
Apr 03 01:31:10 laptop kernel: DMAR: Setting RMRR:
Apr 03 01:31:10 laptop kernel: DMAR: Prepare 0-16MiB unity mapping for LPC
Apr 03 01:31:10 laptop kernel: DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
Apr 03 01:31:10 laptop kernel: DMAR: Intel(R) Virtualization Technology for Directed I/O
Apr 03 01:31:10 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:10 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 0 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c000000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c026000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c03c000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c040000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c055000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c06d000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c080000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c095000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c0a9000 [fault reason 01] Present bit in root entry is clear
Apr 03 01:31:26 laptop kernel: DMAR: DRHD: handling fault status reg 3
Apr 03 01:31:26 laptop kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7c0bd000 [fault reason 01] Present bit in root entry is clear

With the old coreboot I only got the very first line (IOMMU enabled and that’s it), so will look that way next, but it’s already past 2AM and I should work on fixing my jetlag instead of doing this right now

I’ll probably test again without igvt during the week, but if someone has a clue first that’ll help

mladen · April 2, 2018, 7:48pm

Could you try booting with intel_iommu=igfx_off kernel boot flag?

kakaroto · April 3, 2018, 9:13pm

Ah, it looks like if you have intel_iommu=on in your kernel arguments, you also need iommu=pt otherwise you get those errors and glitches.
I’m not yet sure on why that actually is required and if you have the time to google it and find out why that passthrough argument is needed, let us know! In the meantime, that’s the solution

Asmadeus · April 3, 2018, 11:09pm

Right, iommu=pt will probably work as well, I hadn’t thought of it. I’ll reflash & test Thursday or Friday as I doubt I’ll have time before that.

If I understand it correctly that still means we’re doing something wrong, though - that pt stands for passthrough and basically the setting just maps everything to where it would be mapped without iommu; folks also say it brings in performance boost for direct device accesses (e.g. “from the hypervisor”) so it might not do remapping at all unless explicitly requested while just iommu=on might use different areas and remap everything.

I’ll report that it works once tested, thanks!

Asmadeus · April 6, 2018, 2:13pm

Friday it is - I can confirm iommu=pt works. And igvt (intel graphics virtualisation) still works, so no problem on that end except that I had to add the extra flag.

I still think that means something somewhere isn’t correct but I honestly don’t care enough, thanks for the hint. You might want to add a README to your coreboot-files repo and write that eventually?

kakaroto · April 9, 2018, 8:13pm

Yeah, something somewhere is still not right, but I don’t know what it would be. Matt (other coreboot dev) is looking into it, he confirmed that igvt works without iommu=pt on the AMI firmware and he also confirmed that adding the RMRR structures to the DMAR ACPI table doesn’t fix it, so we’re not yet sure what the issue is and he’s still looking into it. Hopefully he can find and fix that for the next release.

Asmadeus · April 9, 2018, 10:53pm

Cool! Thanks for the update, it’s not much but it would definitely be great if this can be figured out; I’m curious what else there could be; the ACPI table was a good idea.
Basically there must be somewhere reporting the correct addresses to use for the driver that we don’t fill in right, but looking at the code I don’t see where it is getting that information so I won’t be of much more help

Thanks anyway, keep up the good work!

kakaroto · July 5, 2018, 10:46pm

Hi,
Just an update here, we finally figured out the problem, it was the RMRR structures after all, they were just wrongly set and I was able to find how to determine the correct values and set it. We now have a working coreboot without the need for iommu=pt and without video glitches when iommu is enabled. We’re currently working on getting a new update out with the fix, so expect it soon!
Thanks for your patience

Asmadeus · July 5, 2018, 11:45pm

Nice! Thanks for reporting back, I’ll definitely test that once you’ve gotten the update out

kakaroto · July 10, 2018, 5:17pm

Boot script is updated and the release that fixes the DMAR issues is out! enjoy!

Asmadeus · July 18, 2018, 1:29pm

Took me a week, but I can confirm booting without iommu=pt and igvt works like a charm as before, good job!

Thanks again for the update