Contribute
Register

Custom ETH0 SSDT

Status
Not open for further replies.
I see 3 options (more experienced ACPI developers may have other ideas):
  1. Inject properties using Clover Configurator.
  2. Modify DSDT.aml and remove the if statement by deleting the 3 lines in the 2 red boxes.
    • Then save the modified .aml file to your CLOVER/ACPI/patched folder.
    • Reboot.
    • Then run the Terminal log command again and post the file.
  3. If option 2 does not work, undo the change (put the if statement back). Then try this:
    • Put your DSM method inside the DSDT itself.

Options 2 and 3 are out, giving me instant KP upon boot attempt. 1st Option injects correct information, but somehow I get the feeling I'm overlooking something, because the arbitrary section in devices is yet another workaround for SSDTs, if you will, correct? So it doesn't make any sense to me that this section in the config has access to injecting properties, while the SSDT has not. This is one iffy mess of a system, I got myself here :banghead:

But nevertheless, thanks for your help, you're one hell of a mod :thumbup:

PS. I too would like to live without the XDSM conversion, would make my config yet a bit simpler, but for the time being there seems no way around it...

Maybe it's time to consult @kgp now :geek:
 
Fun fact: you can rename the _DSM Methods in your SSDTs to XDSM; info will be visible via IOReg, but not the PCI section in SysInfo. Devices LPCB and ESPI also won't get "assigned" to their drivers
 
Options 2 and 3 are out, giving me instant KP upon boot attempt. ...

I have attempted far more evil changes to my DSDT without ever encountering a kernel panic! We have to be sure that the modified version compiles without errors/warning. I always rename my modified file, however. For example, I use "DSDT-TEST1.aml". Then I enter this full name in Clover Configurator --> Acpi as shown:

Screen Shot 2019-10-22 at 5.38.21 PM.png

So perhaps try again with a simple modification to GLAN, such as just adding a DSM method, but keeping it empty. See if the system still panics.

If it works, then add one or two items to the DSM method at a time.

Clover devices --> Arbitrary uses a different method to inject properties, so it is worth trying if the DSDT/SSDT patching method fails.
 
I have attempted far more evil changes to my DSDT without ever encountering a kernel panic!

That's the reason, why I called it fickle an highly sensitive: it alway's seems to get it's way. But I'll try again, once I'm back from work (8:14am here in Germany now :D)
 
Last edited:
Another fun aside:

The most evil thing I did with my DSDT was to copy the Thunderbolt hot-plug SSDT into it. It still worked.
 
So perhaps try again with a simple modification to GLAN, such as just adding a DSM method, but keeping it empty. See if the system still panics.

Either I am too tired, or too dumb, but system panics, as soon as I put the DSDT in ACPI/patched, whether untouched, or modified, whether I drop the OEM table, or not. This is not the first time I'm applying a patched DSDT, but this bugger is freaking me out.
 
Either I am too tired, or too dumb, but system panics, as soon as I put the DSDT in ACPI/patched, whether untouched, or modified, whether I drop the OEM table, or not. This is not the first time I'm applying a patched DSDT, but this bugger is freaking me out.
  • Have you tried a different name such as DSDT-TEST1.aml?
  • Have you tried adding an empty DSM method (or even a fake method such as method FAKE to a different device in DSDT?
  • Also, please check which version of Clover you're running. Try updating to at least v4961.
 
  • Have you tried a different name such as DSDT-TEST1.aml?
  • Have you tried adding an empty DSM method (or even a fake method such as method FAKE to a different device in DSDT?
  • Also, please check which version of Clover you're running. Try updating to at least v4961.

Points 1 and 2 are done. It happens as soon, as the DSDT gets in the patched folder, no matter the name, or methods.

Clover is on v5097. Quite the system, wouldn't you agree? :mrgreen:
 
Points 1 and 2 are done. It happens as soon, as the DSDT gets in the patched folder, no matter the name, or methods.

Clover is on v5097. Quite the system, wouldn't you agree? :mrgreen:
Just to belabor the point -- you tried adding an empty DSM or FAKE method to a different device (not GLAN) and still...to quote Bruce Willis in The 5th Element, it went bada boom??

I wonder if Change _DSM to XDSM is causing conflicts with a modified DSDT...
 
Status
Not open for further replies.
Back
Top