Drop DMAR Table vs DisableIOMapper

[J Lamp]

I could use a little clarification on this on.

 

My config.plist files have always had DMAR listed in the Drop Tables section. As I've now updated Clover from 5122 to 5149 (so I can move on from Mojave) it seems that the DMAR table is no longer being dropped.

 

I had simply (and incorrectly it seems) assumed that I could use my old config.plist, modify it in the latest Clover Configurator and that would add the required quirks to work with the new OpenCore memory management. Using BBEdit and looking at the the sample config.plist that came with version 5149, I can see that there are a whole bunch of default OpenCore quirks set in that plist that don't show up in Clover Configurator. One of those is DisableIOMapper, which is set to true. If I understand it right, that removes the DMAR table.

 

Slice had suggested that I modify my DMAR table (apparently I should remove the "Reserved Memory" section) and create a custom SSDT so that I can allow VT-D to enable my 10G network in Monterey and not have to use dart=0 when booting Mojave. It seems though, that when I use MacIASL > New From ACPI, I still have the original DMAR table, when I add my modified one MacIASL shows 2 DMAR tables and when I try to use "AutoMerge" in Clover Configurator I get a panic no matter what OS I try to boot. Using the Drop Tales section to drop DMAR doesn't seem to be working.

 

Just so I'm clear moving forward, what's the status on the "Drop Tables" section in the config.plist? Should I be using "DisableIOMapper" to drop DMAR and if so, is it just DMAR that is affected or are there other tables as well that should be dealt with using the new OpenCore methods?

 

Edit - Just a quick update, enabling "DisableIOMapper" breaks my AQN-107 ethernet card, even with a customized DMAR table installed. The DAMR table still shows up as well. Maybe I'm just doing something wrong.

Edited October 7, 2022 by J Lamp

[etorix]

The overall purpose is to have Intel VT-d working.

To achieve this:

• VT-d must be enabled in BIOS;
• DisableIOMapper quirk must be disabled;
• there must be a DMAC (Direct Memory Access Controller) device (look for 'PNP0200' in DSDT, if there is one device with this _HID property, it's fine; if here is none, add SST-DMAC).

And, for the proper working of all devices, macOS must be able to access all memory regions it wants to access. This is where the DMAR table (DMA Remapping) comes into play. Inspect the native DMAR table and look for any reserved regions. If there are no reservations, you're all fine.

If there are reservations in DMAR, make a copy of the table and delete the reserved regions: This becomes your custom SSDT-DMAR. Then drop the native DMAR table ("Drop Tables" in Clover; ACPI>Delete in OpenCore, TableSignature: DMAR) and add your custom SSDT-DMAR instead. (This is the same as dropping the native DSDT and replacing it by a modified version: To replace completely, the original table must be dropped; and if a table if dropped, there must be a replacement.)

 

You may post your native DMAR (or your whole set of ACPI tables) here.

Edited October 8, 2022 by etorix
typo

[J Lamp]

Hi etorix:

 

Thanks very much for the reply.

 

Yes I understand that I need to have VT-D working for the latest few versions of MacOS and I do have it working, otherwise my Aquantia network card doesn't fire up.

 

I also understand that I should use a patched DMAR (remove the Reserved Memory sections) and with that I should be able to boot up prior OS's (such as Mojave) without any trouble using the patched DMAR and without dart=0.

 

My question however was specifically about using "Drop Tables" and DMAR. Using Clover 5149 it's not dropping the original DMAR table. If I try to use the patched one I end up seeing 2 DMAR tables when I use MaciASL > New from ACPI

 

I just tried booting with Clover 5122 and an older Mojave install, dropping the DMAR table is working correctly there.

 

I had thought that since aspects of OpenCore are now part of Clover perhaps I was supposed to use a different method to drop the DMAR table. From what I've read it looks like the OC quirk DisableIOMapper is somewhat equivalent to using dart=0, but neither of those allow the original or the alternate patched DMAR to function.

 

As I've read a bunch of posts regarding this, it certainly sounds like most people are having success. I did find a guy on Reddit having exactly the same problem as me. Reddit - Dropping DMAR in Clover 5146 I tried the suggested method there of enabling AutoMerge to replace the original DMAR with the patched one, but when I did that I got a panic during boot no matter what version of MacOS I try to load.

 

It would seem like a software regression in Clover, but others, such as yourself, seem to have it working, so I thought that maybe there was a new way of going about dropping the DMAR table that I was missing.

 

I don't have another machine handy here to test this on, but on my x299 rig Clover 5149 is definitely not dropping the original DMAR table.

[etorix]

I do not use Clover, and I'm not very familiar with it. But I think that dropping ACPI tables should be independent from the OpenCore-inherited quirks.

 

DisableIoMapper disables VT-d, so this must be off. There should be no 'dart=0' argument and VT-d must be enabled in BIOS.

Can you boot with these settings? Not trying to drop DMAR or adding your own SSDT-DMAR at this stage.

[J Lamp]

Understood about DisableIOMapper and dart=0, I was looking at these because dropping the DMAR table wasn't working and I thought I was simply missing something new.

 

I can boot Monterey without any trouble. The DMAR table gets passed to the OS regardless of the "Drop Tables" setting in Clover. It seems that I don't need to remove the Reserved Memory section for Monterey, it works fine.

 

I cannot boot Mojave though with Clover 5149 unless I use dart=0. The original DMAR table is passed to the OS and it panics early in the boot process. I need to use dart=0.

 

I just tried this with Clover 5122 (which I know does drop the DMAR table correctly) loading Mojave and using the patched SSDT-DMAR.aml, it panicked during boot anyway.

 

So for now I think he simplest thing for me to do is stick with a custom entry for my Mojave drive that injects dart=0 for that OS. Everything in Mojave works fine without VT-D, including all the network cards.

 

I very much appreciate your help on this etorix, you've helped me get a much better sense of what's going on and where the problem is. Cheers!

[Alexey Boronenkov]

This is how you can delete a DMAR table in OpenCore and add your modified one

[Slice]

With recent Clover DMAR table is dropped successfully. 

[J Lamp]

Sorry to resurrect this old thread @Slice, but you and I have been chatting on the AQC107 support thread about my card not working in 14.5 and as I've been investigating it seems that the DMAR table is not getting dropped again.

 

If I use a patched DMAR table and have Drop Tables set for DMAR, I still see both DMAR tables when using MacIASL > New From ACPI.

 

I'm wondering if the Reserved Memory that is in my original DMAR table is possibly causing the problem with the AQC107. 

 

I'm using Clover 5158.

[Slice]

There are two pointers of ACPI tables in memory, RSDT and XSDT. MaciAsl extract both chains while macOS uses only tables from XSDT. For the system there is one DMAR which is loaded by Clover.

[J Lamp]

Yes, understood that is the expected behaviour.

 

With VT-d enabled in BIOS and the DMAR table dropped in Clover I still have Mac loading VT-d. If I use MacIASL to extract the DMAR table (while I have Clover set to drop the DMAR table) I get exactly the same output as I have from my extracted DMAR table from using F4 at the boot loader screen. They are identical.

 

If I then put a patched DMAR table in ACPI/Patched and use MacIASL I have 2 DMAR tables listed, DMAR and DMAR-1.

 

I know that there are Reserved Memory regions in the unpatched DMAR table. The strange part is, if I do not add the entry in Clover to drop the DMAR table I get a panic early in the boot process. If I do have Clover set to drop the table the x299 rig will boot and apparently load the table anyway (Apple VT-d is working and so is my AQC107 for quite a long time now, until recently.)

 

I tried adding the patched table to see if it would fix my AQC107 problems, but even with the DMAR table set to be dropped I still end up with apparently 2 DMAR tables loaded.

 

 

[Slice]

Try Xiasl instead of MacIasl.

[Slice]

DarwinDumper 

shows me one DMAR even if I drop native DAME and upload patched one.

 

My clover config

 

And ACPI folder

 

The table extracted by DarwinDumper is the same as my loaded DMAR-2.aml

 

[J Lamp]

@Slice, sorry for the slow response to this, I've been tied up with work lately.

 

Imagine 3 scenarios, in every one of these situations I have VT-d enabled in the bios.

 

Scenario 1: I have VT-d enabled and I do not have config.plist set to drop the DMAR table, I get a panic early in the boot process.

 

Scenario 2: I have VT-d enabled in BIOS and I have the config.plist set to drop the DMAR table. There is no patched DMAR table in EFI>Clover>ACPI>Patched. I get the following;

 

As you can see I have dropped the DMAR table, but somehow it loads anyway. Darwin Dumper can extract the table and if I decompile it, it is that same as the one I extracted from the Cover boot screen, it has the Reserved Memory regions. Apple loads VT-d  and my AQC107 card works (rock solid, till 14.5)

 

Scenario 3: I have VT-d enabled in the Bios, I have Clover set to drop the DMAR table and I have a patched DMAR in EFI>Clover>ACPI>Patched. This is what I get;

 

As you can see I now have 2 DMAR tables. If I decompile them one is the original with the Reserved Memory regions and one is my edited one without them.

 

Clearly dropping the DMAR table is doing something, otherwise the x299 won't boot, but still the table is getting loaded. This is beyond my ability to figure out. Hopefully with this info and your expertise we can get to the bottom of it. If there is anything that you want me to try on my end please let me know.

 

Thanks.

 

[Slice]

It looks like you have quirky ACPI tables in BIOS so dropping one DMAR you have second one.

Something written in preboot.log?

[J Lamp]

I think this is what you are looking for. I don't see anything strange in there (related to this anyway.)

bdmesg.txt

 

The Kernel Log shows all acpi tables listed twice, I don't know if that is right.

Kernel_Boot_Messsages.txt

Edited June 9 by J Lamp
Additional Info

[Slice]

This is strange.

Your log

10:360  0:000  === [ ACPIDropTables ] ==========================
10:360  0:000  Drop tables from XSDT, SIGN=DMAR TableID=A M I  Length=264
10:360  0:000  OCABC: AllocPages 1 0x4AB57000 (2) - Success

My log (today)

182:280  0:000  === [ ACPIDropTables ] ==========================
182:280  0:000  Drop tables from XSDT, SIGN=SSDT TableID=A M I Length=3806
182:280  0:000   Table[11]: SSDT  A M I  3806 dropped
182:280  0:000  Drop tables from XSDT, SIGN=DMAR TableID=A M I Length=112
182:280  0:000   Table[18]: DMAR  A M I  112 dropped
182:280  0:000  OCABC: AllocPages 1 0x5E778000 (2) - Success

So I see DMAR dropped while not in your case.

Try to drop one more table, for example DBG2 , if you are not going to make debug from remote computer. So you will drop two tables.

I expected you will see DMAR really dropped.

 

Thanks for the note. It looks like a bug.

[Slice]

Probably GetFadt() is not correctly working on your hardware. Debug required.

[J Lamp]

On 6/9/2024 at 3:32 PM, Slice said:

Try to drop one more table, for example DBG2 , if you are not going to make debug from remote computer. So you will drop two tables.

I expected you will see DMAR really dropped.

Sorry to say that didn't change anything.

 

I've booted in debug mode (log is attached.) I'm unsure about reading that log, though from what I can see the debug log seems to suggest that DMAR is getting dropped, it's not, Darwin Dumper still extracts it and Apple is still loading VT-d

 

 

2024-06-13_13-11_BOOTX64.EFI.log

[Slice]

On 6/13/2024 at 4:18 PM, J Lamp said:

Sorry to say that didn't change anything.

 

I've booted in debug mode (log is attached.) I'm unsure about reading that log, though from what I can see the debug log seems to suggest that DMAR is getting dropped, it's not, Darwin Dumper still extracts it and Apple is still loading VT-d

 

 

2024-06-13_13-11_BOOTX64.EFI.log 89.79 kB · 0 downloads

Show me your config.plist. I can't understand why your DMAR is not dropped. I checked this several ways and always success.

[J Lamp]

Thanks for having a look @Slice, here you go...

config.plist.zip

[miliuco]

@J Lamp

I don't see DMAR table dropped in config.plist.

After dropping DMAR, Automerge=True can help, there is issues with MacIASL > New From ACPI (see Automerge by @cankiulascmnfye )

https://github.com/5T33Z0/Clover-Crate/tree/main/ACPI#readme

 

Edited June 23 by miliuco

[Slice]

17 hours ago, J Lamp said:

Thanks for having a look @Slice, here you go...

config.plist.zip 4.04 kB · 1 download

But you set DropForAllOS as false that means don't drop at all!!!! 

 

[cankiulascmnfye]

9 hours ago, miliuco said:

@J Lamp

I don't see DMAR table dropped in config.plist.

After dropping DMAR, Automerge=True can help, there is issues with MacIASL > New From ACPI (see Automerge by @cankiulascmnfye😞

https://github.com/5T33Z0/Clover-Crate/tree/main/ACPI#readme

 

DMAR not being dropped is a Clover issue. I reported it before… and like most Clover issues it just got ignored and was downplayed as "user error" .

[Slice]

On 6/23/2024 at 10:05 PM, cankiulascmnfye said:

 

DMAR not being dropped is a Clover issue. I reported it before… and like most Clover issues it just got ignored and was downplayed as "user error" .

 

On 6/17/2024 at 9:01 PM, Slice said:

Show me your config.plist. I can't understand why your DMAR is not dropped. I checked this several ways and always success.

 

[J Lamp]

@Slice I had assumed that "DropForAllOS" would drop it for Windows as well, which I do not want. It seems I had misunderstood the setting.

 

@miliuco that's a great link, thanks for the info!

 

I will try both methods (changing "DropForAllOS" and alternately the "Automerge" setting) and will report back.

 

Thanks.