Search results

And here's the whole heap of discussion around I225-V issue too. LAN/WiFi/Bt is the major hurdle in our little garden, isn't it...

I've been fed-up with ASRock ACPI for a while and was considering moving to something else. But never got around it since it worked good enough until now, when it became apparent that SmallTree is dead in the water and my X570 ITX/TB3 uses I211-AT. MSI is a no-go due to their BIOS shenanigans...

I usually use any kind of merge tool that can visually display differences in text files. Then compare Docs/Sample.plist from the version I have to version I'm upgrading to. Then open your config.plist and add/adjust as needed. From 0.7.4 to 0.7.5, there are just two differences and it's two...

Just now seeing this. Jiminy! Take care and take all the time you need to sort this out. I am glad there was no fire as consequence given how much stuff died.

Daaaamn - a random lock-up on wake today, after days and days of all working fine. Really wish I knew how to track this down. I tried in the past with DEBUG builds and DebugEnhancer.kext and acpi-*** boot args and what not. Either I did not know how to setup/use all that or it did not reveal...

Checked in Windows, there's definitely no EC device on this motherboard. ACPI tables are identical, regardless of BIOS settings. I am tempted to just suppress these two SSDT tables as it looks a bunch of leftover garbage, probably from some other board. Maybe even Z490 of the same name :)

I am wondering something: do BIOS changes influence the ACPI tables MaciASL is able to extract? I will test this at some point in Windows, by reseting BIOS to defaults and then extract ACPI tables there. Reason for such thinking: there are 19 (!) unknown external methods in this one...

Looking at all DSDT / SSDT from ASRock ACPI, I found it. In one of the SSDTs there's: Scope (\_SB.PCI0.LPC0.EC0) { Method (XQ51, 0, NotSerialized) { \_GPE.EE1B () } Method (XQ52, 0, NotSerialized) { \_GPE.EE1B () }...

OpenCore's sample SSDT adds MCHC and SBUS devices. What is this MCHC device doing, why it's added in the first place? I can't find it anywhere in real MacPro's DSDT/SSDT. BTW, looking for explanation what MCHC is, I found this amazing repository which is translation from Daliansky's...

Here are screenshots from real MacPro7,1 (sadly, I don't the exact config).

Hm, but when you check in IORegExplorer, SMBus is gone from IOService. Thus it seems that checking just for kexts may not be enough. I'm confused now, will need to look at iOReg from real MacPro.

One thing I wondered for quite a while regarding SMBus support. At the end of the Dortania article, there's a terminal command to check is the SSDT working: kextstat | grep -E "AppleSMBusController|AppleSMBusPCI" I disabled the SSDT and checked output from this command: % kextstat | grep -E...

I am growing more confident the SSDT-GPRW from few posts back is the winner. Dozen of sleep/wake cycles went through, works great. Regardless of using wired or BT keyboard, it sleeps and wakes up reliably. @Shaneee – try with that one, could possibly work for you. Unless something suddenly...

My internal Bluetooth hub is on the XHC that falls under the 0x03. The last 3 sleep / wakes I did was either with mouse (Glorious MOW, has its own USB adapter) or Bt keyboard (Keychron K1). I don't personally care what I use to wake up the machine, as long as both peripherals are working after...

I tried that and nope - it is not responding at all. So far I am testing without WEG and bare minimum of SSDTs and kexts. I have lots of stuff to do over the weekend, so will set 1-2min sleep time and see how it behaves.

I'm not sure I can help. I never had shutdown issues with this build.

Hey, that's awesome. Please do report your tests - more tests, the merrier. With the previous version of SSDT-GPRW, sleep/wake would often work but then occasionally would go to sleep but then half-wake up after 10-20s (not sure). Screen would be dead but rest of the comp would seem alive...

Then switch to original BIOS for 5700 and see if black screens are gone. If not, something else is an issue.

Aluveitie sent me to well of knowledge with no end. I have 10+ tabs open, full of dense information regarding the infamous _PWR method. This Sleep / Wake thing is amazing, really. For starters, a refresher what sleep states exist: Gx Name Sx Description G0 Working S0 The computer is...

Quite possibly. I honestly can't understand what you expected to gain with that flashing. Do you even see any meaningful performance increase, worthy of risking the entire card..? It's not like all those disabled compute units will suddenly spring to life with new firmware. Even if that could...