Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation on DisableIoMapperMapping quirk is incorrect #2278

Closed
justinkb opened this issue May 9, 2023 · 20 comments
Closed

Documentation on DisableIoMapperMapping quirk is incorrect #2278

justinkb opened this issue May 9, 2023 · 20 comments

Comments

@justinkb
Copy link

justinkb commented May 9, 2023

On macOS 13.3, I definitely need this quirk enabled on Gigabyte Z390 Aorus Master motherboard, even though I have iGPU completely disabled.

acidanthera/OpenCorePkg@e98da12 is the commit that updated the docs incorrectly

@mikebeaton
Copy link
Contributor

cc @CaseySJ

@CaseySJ
Copy link

CaseySJ commented May 9, 2023

My own testing on Gigabyte Z390 Designare showed that disabling iGPU restored WiFi and Ethernet without enabling the quirk. A handful of others on TonyMac reported the same outcome. Please see this: https://www.tonymacx86.com/threads/gigabyte-z490-vision-d-thunderbolt-3-i5-10400-amd-rx-580.298642/post-2366556

It is possible that the behavior is different on other motherboards. I have no problem revising the documentation (perhaps changing “and” to “and/or”), but let’s wait a little for more feedback.

@mikebeaton
Copy link
Contributor

mikebeaton commented May 9, 2023

@justinkb - Could you upload some test result or screenshot confirming that iGPU is definitely disabled, please?

Assuming all checks out, suggest:

  This option resolves compatibility issues with Wi-Fi, Ethernet and
  Thunderbolt devices when AppleVTD is enabled on systems where the native DMAR table
  contains one or more Reserved Memory Regions and more than 16 GB memory is installed.
  On some systems, this quirk is only required when iGPU is enabled.

@justinkb
Copy link
Author

justinkb commented May 9, 2023 via email

@justinkb
Copy link
Author

justinkb commented May 9, 2023 via email

@mikebeaton
Copy link
Contributor

@CaseySJ Are you okay with the suggested changed wording?

@CaseySJ
Copy link

CaseySJ commented May 9, 2023

@CaseySJ Are you okay with the suggested changed wording?

@mikebeaton I believe it's always necessary to drop Reserved Memory regions from DMAR.

@justinkb Please confirm if you're dropping the original DMAR table and replacing it with a modified version that excludes Reserved Memory regions.

@perez987
Copy link

perez987 commented May 9, 2023

Good afternoon. Z390 Aorus Elite. VT-d enabled in BIOS. RAM 32GB. 13.3.1 (a). DMAR table has Reserved Memory Regions.

  • Disabling iGPU plus DMAR dropped >> both DisableIo quirks not needed.

  • Disabling iGPU plus native DMAR >> no wifi nor Eth with DisableIo quirks false. DsableIoMapper is not enough. DisableIoMapperMapping also required.

@mikebeaton
Copy link
Contributor

So from @justinkb and @perez987 reports, original PR acidanthera/OpenCorePkg@e98da12 is wrong, and we should just drop the wording 'and iGPU is enabled'?

@CaseySJ
Copy link

CaseySJ commented May 9, 2023

This may be a better option:

  This option resolves compatibility issues with Wi-Fi, Ethernet and
  Thunderbolt devices when AppleVTD is enabled on systems where the native DMAR table
  contains one or more Reserved Memory Regions and more than 16 GB memory is installed.
  On some systems, this quirk is only needed when iGPU is enabled.

  This quirk requires a native DMAR table that does not contain Reserved Memory
  Regions or a substitute SSDT-DMAR.aml in which Reserved Memory Regions
  have been removed.

@mikebeaton
Copy link
Contributor

Again, I don't have any machine this applies to, but if you're also happy with that @justinkb then it looks reasonable to me, and I can update.

@justinkb
Copy link
Author

justinkb commented May 10, 2023

I'll describe the exact details of my setup for Casey, so he can take another look at things.

I don't actually drop DMAR as such, but patch its checksum and length (padding over the reserved memory region at the end of the table with zero bytes)

DMAR table dsl when booting without opencore

[000h 0000 004h]                   Signature : "DMAR"    [DMA Remapping Table]
[004h 0004 004h]                Table Length : 00000070
[008h 0008 001h]                    Revision : 01
[009h 0009 001h]                    Checksum : EF
[00Ah 0010 006h]                      Oem ID : "ALASKA"
[010h 0016 008h]                Oem Table ID : "A M I"
[018h 0024 004h]                Oem Revision : 00000002
[01Ch 0028 004h]             Asl Compiler ID : "    "
[020h 0032 004h]       Asl Compiler Revision : 01000013

[024h 0036 001h]          Host Address Width : 26
[025h 0037 001h]                       Flags : 01
[026h 0038 00Ah]                    Reserved : 00 00 00 00 00 00 00 00 00 00

[030h 0048 002h]               Subtable Type : 0000 [Hardware Unit Definition]
[032h 0050 002h]                      Length : 0020

[034h 0052 001h]                       Flags : 01
[035h 0053 001h]                    Reserved : 00
[036h 0054 002h]          PCI Segment Number : 0000
[038h 0056 008h]       Register Base Address : 00000000FED91000

[040h 0064 001h]           Device Scope Type : 03 [IOAPIC Device]
[041h 0065 001h]                Entry Length : 08
[042h 0066 002h]                    Reserved : 0000
[044h 0068 001h]              Enumeration ID : 02
[045h 0069 001h]              PCI Bus Number : 00

[046h 0070 002h]                    PCI Path : 1E,07


[048h 0072 001h]           Device Scope Type : 04 [Message-capable HPET Device]
[049h 0073 001h]                Entry Length : 08
[04Ah 0074 002h]                    Reserved : 0000
[04Ch 0076 001h]              Enumeration ID : 00
[04Dh 0077 001h]              PCI Bus Number : 00

[04Eh 0078 002h]                    PCI Path : 1E,06


[050h 0080 002h]               Subtable Type : 0001 [Reserved Memory Region]
[052h 0082 002h]                      Length : 0020

[054h 0084 002h]                    Reserved : 0000
[056h 0086 002h]          PCI Segment Number : 0000
[058h 0088 008h]                Base Address : 000000002F899000
[060h 0096 008h]         End Address (limit) : 000000002FAE2FFF

[068h 0104 001h]           Device Scope Type : 01 [PCI Endpoint Device]
[069h 0105 001h]                Entry Length : 08
[06Ah 0106 002h]                    Reserved : 0000
[06Ch 0108 001h]              Enumeration ID : 00
[06Dh 0109 001h]              PCI Bus Number : 00

[06Eh 0110 002h]                    PCI Path : 14,00


Raw Table Data: Length 112 (0x70)

    0000: 44 4D 41 52 70 00 00 00 01 EF 41 4C 41 53 4B 41  // DMARp.....ALASKA
    0010: 41 20 4D 20 49 00 00 00 02 00 00 00 20 20 20 20  // A M I.......    
    0020: 13 00 00 01 26 01 00 00 00 00 00 00 00 00 00 00  // ....&...........
    0030: 00 00 20 00 01 00 00 00 00 10 D9 FE 00 00 00 00  // .. .............
    0040: 03 08 00 00 02 00 1E 07 04 08 00 00 00 00 1E 06  // ................
    0050: 01 00 20 00 00 00 00 00 00 90 89 2F 00 00 00 00  // .. ......../....
    0060: FF 2F AE 2F 00 00 00 00 01 08 00 00 00 00 14 00  // ././............

When booting with OpenCore

[000h 0000 004h]                   Signature : "DMAR"    [DMA Remapping Table]
[004h 0004 004h]                Table Length : 00000050
[008h 0008 001h]                    Revision : 01
[009h 0009 001h]                    Checksum : 9C
[00Ah 0010 006h]                      Oem ID : "ALASKA"
[010h 0016 008h]                Oem Table ID : "A M I"
[018h 0024 004h]                Oem Revision : 00000002
[01Ch 0028 004h]             Asl Compiler ID : "    "
[020h 0032 004h]       Asl Compiler Revision : 01000013

[024h 0036 001h]          Host Address Width : 26
[025h 0037 001h]                       Flags : 05
[026h 0038 00Ah]                    Reserved : 00 00 00 00 00 00 00 00 00 00

[030h 0048 002h]               Subtable Type : 0000 [Hardware Unit Definition]
[032h 0050 002h]                      Length : 0020

[034h 0052 001h]                       Flags : 01
[035h 0053 001h]                    Reserved : 00
[036h 0054 002h]          PCI Segment Number : 0000
[038h 0056 008h]       Register Base Address : 00000000FED91000

[040h 0064 001h]           Device Scope Type : 03 [IOAPIC Device]
[041h 0065 001h]                Entry Length : 08
[042h 0066 002h]                    Reserved : 0000
[044h 0068 001h]              Enumeration ID : 02
[045h 0069 001h]              PCI Bus Number : 00

[046h 0070 002h]                    PCI Path : 1E,07


[048h 0072 001h]           Device Scope Type : 04 [Message-capable HPET Device]
[049h 0073 001h]                Entry Length : 08
[04Ah 0074 002h]                    Reserved : 0000
[04Ch 0076 001h]              Enumeration ID : 00
[04Dh 0077 001h]              PCI Bus Number : 00

[04Eh 0078 002h]                    PCI Path : 1E,06


Raw Table Data: Length 80 (0x50)

    0000: 44 4D 41 52 50 00 00 00 01 9C 41 4C 41 53 4B 41  // DMARP.....ALASKA
    0010: 41 20 4D 20 49 00 00 00 02 00 00 00 20 20 20 20  // A M I.......    
    0020: 13 00 00 01 26 05 00 00 00 00 00 00 00 00 00 00  // ....&...........
    0030: 00 00 20 00 01 00 00 00 00 10 D9 FE 00 00 00 00  // .. .............
    0040: 03 08 00 00 02 00 1E 07 04 08 00 00 00 00 1E 06  // ................

Based on this, it looks like Casey's suggested documentation text is fully accurate now

@CobanRamo
Copy link

just for understanding; sorry for this stupid question...

now does this quirk need a patched DMAR table to be enabled or to be disabled?

In what state must the DMAR table be patched with multiple Reserved Areas?

"{Note 1}: This quirk requires a native DMAR table that does not contain Reserved Memory Regions or a substitute SSDT-DMAR.aml in which Reserved Memory Regions have been removed."

That reads as if you would need a patched DMAR table with the activated Quirk.

@CaseySJ
Copy link

CaseySJ commented May 10, 2023

@CobanRamo,

This quirk is optional. If you are not encountering WiFi and Ethernet connection issues in macOS 13.3 and newer, then you may ignore this quirk.

Some comments/answers:

  1. This quirk applies to macOS Ventura 13.3 and newer when AppleVTD is enabled and WiFi, Ethernet and certain Thunderbolt devices no longer connect, but they used to connect and work in Ventura 13.2 and earlier versions of macOS
  2. If your motherboard's native DMAR table contains one or more Reserved Memory Regions and you have more than 16GB memory installed, then it's necessary to remove those Reserved Memory Regions by (a) dropping the native DMAR table and injecting a substitute SSDT-DMAR.aml in which those memory regions have been removed

@5T33Z0
Copy link

5T33Z0 commented May 25, 2023

I have a Gigabyte Z490 Vision G which stopped working in Monterey beta 5 or so, but for a different reason which I think is unrelated to the iGPU and the amount of installed RAM.

The device header/descripter of the Intel I225-V NIC on that board is incorrect. 2 Methods for fixing it were discovered: either flashing a modified ROM or using an SSDT, dropping/replacing DMAR and injecting AppleIntel210Ethernet kext in Ventura both explained here.

After flashing a modified firmware the problem was resolved for me. Anyway, my point is: I don't think for Gigabyte Z490 boards the amount of RAM or presence/absence of the iGPU is the actual reason for connectivity issues.

@4ppless
Copy link

4ppless commented May 25, 2023

Good afternoon. Z390 Aorus Elite. VT-d enabled in BIOS. RAM 32GB. 13.3.1 (a). DMAR table has Reserved Memory Regions.

  • Disabling iGPU plus DMAR dropped >> both DisableIo quirks not needed.
  • Disabling iGPU plus native DMAR >> no wifi nor Eth with DisableIo quirks false. DsableIoMapper is not enough. DisableIoMapperMapping also required.

For clarification,

  1. Was the IGPU disabled in BIOS?
  2. After dropping native DMAR, did you inject modified DMAR(With no reserved region)

If not, would you mind testing below configuration.

Test to see if wifi/ethernet still works when iGPU is disabled

  • IGPU disabled in BIOS
  • VT-d enabled in BIOS
  • DisableIoMapper - False
  • DisableIoMapperMapping - False
  • Drop native DMAR
  • Inject Modified DMAR

@CaseySJ
Copy link

CaseySJ commented May 29, 2023

I have a Gigabyte Z490 Vision G which stopped working in Monterey beta 5 or so, but for a different reason which I think is unrelated to the iGPU and the amount of installed RAM.

The device header/descripter of the Intel I225-V NIC on that board is incorrect. 2 Methods for fixing it were discovered: either flashing a modified ROM or using an SSDT, dropping/replacing DMAR and injecting AppleIntel210Ethernet kext in Ventura both explained here.

After flashing a modified firmware the problem was resolved for me. Anyway, my point is: I don't think for Gigabyte Z490 boards the amount of RAM or presence/absence of the iGPU is the actual reason for connectivity issues.

I have a Gigabyte Z490 Vision D with Ventura 13.4, and WiFi/Ethernet connectivity are affected by amount of memory. I haven't tested iGPU on/off on this particular system, so cannot make a definitive statement. But on my Gigabyte Z390 Designare, iGPU does have an effect.

@5T33Z0
Copy link

5T33Z0 commented May 29, 2023

@CaseySJ: I think these 2 boards are pretty similar in terms of components. The "D"(=Designare) has an additional I219 NIC and a Thunderbolt header which the "G" (= Gamining) lacks. SInce I flashed a custom ROM on my I225-V, I can't verify the effect RAM has any longer. I have 32 GB. But I know some people who could. Unfortunately, the thread on insanelymac, where the issue was discussed has been deleted.

@CaseySJ
Copy link

CaseySJ commented May 30, 2023

@5T33Z0,

The i225-V on early shipments of the Gigabyte Z490 Vision G and Vision D contained the firmware header/descriptor issue you pointed out. That prevented the i225-V from working, but a firmware update was made available that remedied the problem.

This, however, is a different problem from what the new DisableIoMapperMapping quirk is designed to fix. The quirk applies to Ventura 13.3 and newer.

@5T33Z0
Copy link

5T33Z0 commented May 30, 2023

[…] a firmware update was made available that remedied the problem.

Not a firmware Update I know of. There was one in June 2020 which upgraded the firmware to 1.45 but I had that installed already. This didn't resolve the issue.

Anyway, the take away is:

  • Dropping/replacing DMAR is still required (if it was before) and
  • DisableIoMapperMapping quirk only aids with newly arising connectivity issues in 13.3+ (if they didn't were present before).

I think it should be pointed out more clearly in the Documentation.pdf that "DisableIoMapperMapping" works independently of "DisableIoMapper". The similarity in names suggest some sort dependency on "DisableIoMapper". I've seen cases where both were enable which is not really desirable if AppleVTD needs to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants