Jump to content

Help Installing Big Sur on Xeon W-3375 and Supemicro X12SPA-TF

Balamut

By Balamut,
in OSx86 11.0 (Big Sur)

 Share
133 posts in this topic

Recommended Posts

yapan4
yapan4
Posted
Posted
6 hours ago, Balamut said:

 

Does Clover have CFG Lock quirk? I couldn't find it.

 

 

Really, no. And I didn't delete it, someone did it and I don't know who and when😀 
You still can enable AppleXcpmExtraMsrs Quirk and verify in Clover's GUI -> Option -> Binaries patching -> KernelPM, Clover automatically enable it if locked MSR detected. 

  • Like 1
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

A very clear and comprehensive BIOS!

There are quite a few options I do not understand, and at least one I think I've never seen ("Limit CPU PA to 46 Bits"). Have you identified which options allowed to advance in the boot process?

 

There is no fake EC device in @Loloflat6's SSDT-EC-USBX but one should be needed. You may use the older version (306 bytes).

  • Like 2
Link to comment
Share on other sites
yapan4
yapan4
Posted
Posted (edited)

@Balamut

I checked Clover bootablity with a locked BIOS 2.4 on X11SPA-F - it works, at least on my motherboard. I will find out later where Quirk KernelPatch went.

 

Later I compare your and my BIOS settings, maybe I'll see some differences,,,

@etorix

Also verified  your CPU Wrap SSDT - works perfect.:thumbsup_anim:

Edited by yapan4
  • Like 3
Link to comment
Share on other sites
Loloflat6
Loloflat6
Posted
Posted (edited)

Some progress but :

 

 

Spoiler

 

 

Yeah, there's a persistent breakpoint 🤨

 

So one thing to explore is HEC2

 

Try to boot this SSDT-HEC2 and see if you have gone further 🤔

 

SSDT-HEC2.aml

Edited by Loloflat6
  • Like 2
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

SSDT-PLUG was correct as written: For OS X power management to work, one has to attach the plug-in to the fake Processor() object—in this case \_SB.SCK0.CP00. OS X simply does not detect the processor Device() \_SB.SCK0.C000 and can't do anything with it; that's why CPU wrapping is needed in the first place.

 

As last reported, the lack of a (fake) EC for OS X seems the most obvious issue.

 

If it's not the EC, then indeed there's \_SB.PC00.HEC2. It seems to deal with CPU power management. I'd rather have it initialise properly and work, so I'd try first to disable booter quirks which deal with memory management: AvoidRuntimeDefrag, DevirtualiseMmio, RebuildAppleMemoryMap, SyncRuntimePermissions. One by one, in combination, all of them. The worse that can happen is to find that one or more of them are actually necessary.

From the boot log, EnableCustomeSlide and ProvideCustomSlide are not needed anyway. ProtectUefiServices is not useful if all the quirks it protects are turned off. For what it is worth (possibly nothing at all since it is a board from another manufacturer with another chipset), my Gigabyte C621-SU8 boots reliably with just EnableWriteUnprotector enabled and all other Booter>Quirks disabled—and even requires it that way to install anything older than Big Sur.

 

If nothing works, then I'd try to disable HEC2. It already has a _STA method, so this first requires an ACPI patch 

ACPI
	Patch
		Base		\_SB.PC00.HEC2
		BaseSkip	0
		Comment		HEC2 _STA to XSTA
		Count		1
		Enabled		true
		Find		<5F535441>
		Limit		0
		Mask		<>
		OemTableId	<>
		Replace		<58535441>
		ReplaceMask	<>
		Skip		0
		TableLength	0
		TableSignature	<>

and then a matching SSDT.

SSDT-HEC2-DISABLE.aml

  • Like 2
Link to comment
Share on other sites
  • 2 weeks later...
Balamut
Balamut
Posted
  • Author
Posted

Hi guys, sorry I was MIA for a bit, was out of town for show, last minute thing,

 

On 10/12/2021 at 11:12 AM, Loloflat6 said:

I just re-uploaded SSDT-HEC2 😉

Tried and same issues.

 

 

On 10/12/2021 at 12:56 PM, etorix said:

SSDT-PLUG was correct as written: For OS X power management to work, one has to attach the plug-in to the fake Processor() object—in this case \_SB.SCK0.CP00. OS X simply does not detect the processor Device() \_SB.SCK0.C000 and can't do anything with it; that's why CPU wrapping is needed in the first place.

 

As last reported, the lack of a (fake) EC for OS X seems the most obvious issue.

 

If it's not the EC, then indeed there's \_SB.PC00.HEC2. It seems to deal with CPU power management. I'd rather have it initialise properly and work, so I'd try first to disable booter quirks which deal with memory management: AvoidRuntimeDefrag, DevirtualiseMmio, RebuildAppleMemoryMap, SyncRuntimePermissions. One by one, in combination, all of them. The worse that can happen is to find that one or more of them are actually necessary.

From the boot log, EnableCustomeSlide and ProvideCustomSlide are not needed anyway. ProtectUefiServices is not useful if all the quirks it protects are turned off. For what it is worth (possibly nothing at all since it is a board from another manufacturer with another chipset), my Gigabyte C621-SU8 boots reliably with just EnableWriteUnprotector enabled and all other Booter>Quirks disabled—and even requires it that way to install anything older than Big Sur.

 

If nothing works, then I'd try to disable HEC2. It already has a _STA method, so this first requires an ACPI patch

 

Disabled the quirks and disable the HEC2 and progress, no more HEC2 and memory errors, but still stuck on the PCI Configuration begin.

 

IMG_0160.thumb.jpeg.212ecbe1df88bd7eff3247e1ee96efb9.jpeg

 

 

Can the problem with in the CPUID masks? 

 

Going to download Monterey RC2 and try with it.

 

Thank you all as always for great help.

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites
etorix
etorix
Posted
Posted

Good to hear from you again!

So, HEC2 can be disabled, but it doesn't help. Disabling booter quirks doesn't help either… but does not make things worse, correct?

Have you tried with a fake EC?

Have you tried with HEC2 enabled (not disabled) but the quirks disabled? (To check if one of the memory quirks was responsible for the error and/or whether HEC2 is actually required for boot.)

 

I'm afraid I'm out of ideas for now. But don't give up, it seems to be very close to boot… even if it takes a lot of time, many tries (and quite possibly a fair amount of good luck) to make the last step.

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted

Hi, still playing with different quirks trying to see if any of them are the issue.

 

On 10/25/2021 at 5:23 AM, etorix said:

So, HEC2 can be disabled, but it doesn't help. Disabling booter quirks doesn't help either… but does not make things worse, correct?

Yup it can be and no more memory or EC2 issues, from what I can see no, nothing bad or good.

 

 

On 10/25/2021 at 5:23 AM, etorix said:

Have you tried with a fake EC?

 

Do you mean this one?

  

    Scope (\_SB.PC00.LPC0)
    {
        Device (EC)
        {
            Name (_HID, "ACID0001")  // _HID: Hardware ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }
    }
}

It loads just don't know if it stick on not.

 

 

On 10/25/2021 at 5:23 AM, etorix said:

Have you tried with HEC2 enabled (not disabled) but the quirks disabled? (To check if one of the memory quirks was responsible for the error and/or whether HEC2 is actually required for boot.)

 

Still struggling with trying to enable the HEC2 and I have a suspicion that HEC2 might be the issue with PCI Conf freeze.

 

 

On 10/25/2021 at 5:23 AM, etorix said:

I'm afraid I'm out of ideas for now. But don't give up, it seems to be very close to boot… even if it takes a lot of time, many tries (and quite possibly a fair amount of good luck) to make the last step.

 

I appreciate any help I can get and thankful for all insights. Oh I'm not planing on giving up, I think the W-33xx might be the last MacPro based on Intel and planing on keeping it for a while.

 

 

 

 

  • Like 2
Link to comment
Share on other sites
etorix
etorix
Posted
Posted
3 hours ago, Balamut said:

Do you mean this one?

Yes. AFAIK, having an EC is required to boot, and a failure here would come during PCIe configuration.

 

3 hours ago, Balamut said:

Still struggling with trying to enable the HEC2 and I have a suspicion that HEC2 might be the issue with PCI Conf freeze.

It could be, that's why I hoped that experimenting with the memory-related quirks could allow HEC2 to load.

Options here:

* Find someone who can understand what that code does.  (Hardware WAKe?)

* Find someone who understands memory layouts, why HEC2 cannot initialise its OperationRegion and/or how to select an allowable alternative address for this OperationRegion.

* Failing the above… poking at random. That is, disable the SSDT with the original HEC2 and load a slightly modified SSDT where the OperationRegion points to another address. I have seen the same HEC2 code in SSDTs from different systems, only with a different address for the OperationRegion

(this Supermicro X12SPA-TF: 0x0000200FFFF69000

your Asus WS C621-64L: 0x8000000080000000 in SSDT-4

my Gigabyte C621-SU8: 0x0000383FFFF45000 in SSDT-3

and then the same code, from three different manufacturers—why the different addresses then, and where do they come come from?)

ACPI C621SU8.zip

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted
5 hours ago, etorix said:

Great find! Does HEC2 loads correctly with Above 4G decoding disabled? (Its OperationRegion is below 4G but who knows…)

Yup. No this is with HEC2 disabled, I'll try to enable it tonight with @Loloflat6 SSDT and do more testing.

 

 

4 hours ago, yapan4 said:

In this place you need wait some time until system complete validating root dmg 

For almost 1.5h?

 

Is it possible that ResizeBar is active somewhere hidden and it conflicts with 4G?

 

 

  • Like 1
Link to comment
Share on other sites
etorix
etorix
Posted
Posted (edited)

Ah! We didn't notice that you last screenshot was a caption from an Andy Warhol movie…

Spoiler

Spoiler: If you ever see "Sleep", there's reportedly some action in it: The sleeper turns the other way. Once. In five hours and a half.

 

I had the idea to look again in the DSDT. The two calls to HEC2 methods are conditional (CondRefOf()); if the DSDT does not assume that HEC2 exists, it is presumably NOT critical to boot.

 

The BIOS only contains the sentence "64-bit PCI BAR addresses not supported", within a list of error messages. No hidden option to resize, as far as I can tell.

 

Being serious does not bring any idea, so let's go back to the initial joke: You could actually make a movie of the boot screen to catch the actual panic before the flow of com.apple.xpc.launchd messages.

Edited by etorix
  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)
8 hours ago, etorix said:

Ah! We didn't notice that you last screenshot was a caption from an Andy Warhol movie…

😂

 

 

8 hours ago, etorix said:

I had the idea to look again in the DSDT. The two calls to HEC2 methods are conditional (CondRefOf()); if the DSDT does not assume that HEC2 exists, it is presumably NOT critical to boot.

Looks like Enabling only AvoidRuntimeDefrag, DevirtualiseMmio, EnableWriteProtect, ProvideCustomSlide, Enabling 4G Manages to get me into booting the longest until KP.

 

Couple of things I've noticed.

 

Whatevergreen says that it found unsupported processor.

 

IMG_0199.thumb.jpeg.fccb80a9709dcccbf2596863a7d81212.jpeg

 

 

There is an ACPI Error _STA

 

IMG_0202.thumb.jpeg.2d6607be14c0cd661a7bfea51ebf30ba.jpeg

 

 

 Even with the SSDT still issue with HEC2 (DebugEnhancer is the kext error)

 

IMG_0205.thumb.jpeg.e0c3361ae8ff938a73272e4a7d19ca94.jpeg

 

 

And there is no log on any kernel panics (Sorry for weird photos.)

 

IMG_0208.thumb.jpeg.60bf08f16bf71b04c067e659096a2b53.jpeg

 

IMG_0214.thumb.jpeg.c7d8f62f9d83eb7d1d11f36243e2c752.jpeg

 

 

Just ordered Serial to USB should here by Saturday and hopefully I can finally debug the kernel and see what's the panic is. 

 

Attaching ACPI's just in case (SSDT-HEC2-DISABLE is off in the config).

 

ACPI.zip

 

On the good note XCPM is registered 🤣

 

 

 

 

Edited by Balamut
  • Like 3
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

So it's almost there in many ways and many settings.

 

Best to report to WEG developers to know what is the best way to overcome the issue: -wegbeta, -wegnoigpu (so it doesn't check the CPU?), or no WEG at all if the GPU can work without it.

 

The ACPI error on _STA should come form using a HEC2 SSDT without an ACPI rename _STA -> XSTA, as HEC2 already has a _STA method.

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)

Hey guys, sorry for the late reply, work was kicking my butt.

 

Well after days of testing I finally managed to get a KP in the debug and you never gonna guess on what.

Disabled HT and enabled all the cores. 

com.apple.xpc.launchd|2021-06-21 10:54:11.01626mp2 _(kdspys_etenmte/cro()m. acappn'lte. giecot nsx8e6rv_tiocepos._ilococnk!se rDevibcugesgdin) g< aNonytwicaey!>: # YseOLrOvi
cIOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> AppleSMC
panic(cpu 0 caller 0xffffff801f9e5b53): Kernel trap at 0xffffff7fa1880cfb, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0xffffffd22b03a000, CR3: 0x000000002834c000, CR4: 0x00000000003626e0
RAX: 0xffffff9444fcec00, RBX: 0xffffff9444938940, RCX: 0x000000000000a187, RDX: 0x0000000000000000
RSP: 0xffffffd1b17bbe70, RBP: 0xffffffd1b17bbea0, RSI: 0x0000000040000000, RDI: 0xffffff94449389b2
R8:  0x0000000000000000, R9:  0x0000000000000000, R10: 0x0000000000000000, R11: 0x0000000000000000
R12: 0x0000000000000000, R13: 0x0000000000000019, R14: 0x0000000000000001, R15: 0xffffff9445716480
RFL: 0x0000000000010082, RIP: 0xffffff7fa1880cfb, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0xffffffd22b03a000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 2, VF: 0

Panicked task 0xffffff86cc7326a0: 183 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff86cc71b8b0, Frame : Return Address
0xffffff801f7561f0 : 0xffffff801f89c00d mach_kernel : _handle_debugger_trap + 0x41d
0xffffff801f756240 : 0xffffff801f9f5d85 mach_kernel : _kdp_i386_trap + 0x145
0xffffff801f756280 : 0xffffff801f9e5763 mach_kernel : _kernel_trap + 0x533
0xffffff801f7562d0 : 0xffffff801f83ba60 mach_kernel : _return_from_trap + 0xe0
0xffffff801f7562f0 : 0xffffff801f89c3dd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffff801f756410 : 0xffffff801f89bb96 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffff801f756470 : 0xffffff8020118649 mach_kernel : _panic + 0x54
0xffffff801f7564e0 : 0xffffff801f9e5b53 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffff801f756660 : 0xffffff801f9e5838 mach_kernel : _kernel_trap + 0x608
0xffffff801f7566b0 : 0xffffff801f83ba60 mach_kernel : _return_from_trap + 0xe0
0xffffff801f7566d0 : 0xffffff7fa1880cfb com.apple.driver.AppleIntelMCEReporter : _IOFree + 0x166fcfb
0xffffffd1b17bbea0 : 0xffffff801f9f0361 mach_kernel : _mp_cpus_call_cpu_init + 0x331
0xffffffd1b17bbf10 : 0xffffff801f9efff7 mach_kernel : _cpu_signal_handler + 0x2c7
0xffffffd1b17bbf50 : 0xffffff801f9eefca mach_kernel : _lapic_interrupt + 0x4a
0xffffffd1b17bbf70 : 0xffffff801f9e4f0c mach_kernel : _interrupt + 0x12c
0xffffffd1b17bbfd0 : 0xffffff801f83bc0d mach_kernel : _hndl_allintrs + 0x11d
0xffffffd1b18c3e50 : 0xffffff801f981d97 mach_kernel : _vm_free_delayed_pages + 0x17
0xffffffd1b18c3e70 : 0xffffff801f8d3173 mach_kernel : _max_valid_stack_address + 0x1783
0xffffffd1b18c3fa0 : 0xffffff801f83b18e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.driver.AppleIntelMCEReporter(115.0)[D02C43AA-B75C-3BF4-9F9B-B10F04BB1880]@0xffffff7fa187b000->0xffffff7fa1888fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[7EF77A11-B2B8-3CCF-9188-597E1279EDAC]@0xffffff8021f48000->0xffffff8021f49fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[5E1B0BE0-4B73-35F5-9126-EB05FBB8BAF5]@0xffffff80223ee000->0xffffff8022418fff

Process name corresponding to current thread (0xffffff86cc71b8b0): kernel_task
Boot args: -v serial=5 npci=0x2000 keepsyms=1 debug=0x100 msgbuf=1048576 root-dmg=file:///BaseSystem/BaseSystem.dmg chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21A559

Kernel version:
Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64
Kernel UUID: 19BD4E1B-0268-3EE0-BC66-91F035BC9429
KernelCache slide: 0x000000001f600000
KernelCache base:  0xffffff801f800000
Kernel slide:      0x000000001f610000
Kernel text base:  0xffffff801f810000
__HIB  text base: 0xffffff801f700000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 22255785332
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000052f246afd
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x000001b3c5dd6217 0x0000000000000000
Zone info:
Foreign   : 0xffffff802a3f9000 - 0xffffff802a406000
Native    : 0xffffff81bed98000 - 0xffffffa1bed98000
Readonly  : 0 - 0
Metadata  : 0xffffffd42b387000 - 0xffffffd44ccd1000
Bitmaps   : 0xffffffd44ccd1000 - 0xffffffd48ccd1000

** In Memory Panic Stackshot Succeeded ** Bytes Traced 63530 (Uncompressed 168896) **
IOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> AppleSMC

Some weird observations.

 

When not using npci=0x2000 

  

start() provider ID 0x10000046f, supported 0, update 0
AssertMacros: configSupported,  file: /System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/AppleEthernetAquantiaAqtion/AppleEthernetAquantiaAqtion-178.40.2/AppleEthernetAquantiaAqtion/if_axge.cpp, line: 359, value: 0
AppleEthernetAquantiaAqtion113::waitResetStatus(), timeout 0 (1), mask/value 0x1000000/0x1000000, reset_status 0xc5010000
handleResetEnetHw() [providerID 0x10000046f] AQC113 MIF ID 0x211
AppleEthernetAquantiaAqtion113::waitResetStatus(), timeout 0 (4), mask/value 0xc1000000/0xc1000000, reset_status 0xc5010000
patched fwFilterCaps on behalf of FW
using fwFilterCaps 0x60801000100022c4, fwFilterExtCaps 0x0f018080, RPF ART [8,127]
Still waiting for root device
Still waiting for root device

 

On the side note, does anyone knows why the time is constantly getting messed up in BIOS?

 

 

 

KP Log.txt No Root.txt

Edited by Balamut
  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...