Unsupported NUC8ixBEx panic on wake when in "native" mode

[zearp]

Hello!

I know this is totally unsupported but I can't help trying my luck opening an issue in the hope of solving this panic.

The Coffee Lake NUC8 has the same Thunderbolt chip as the HC one. The patch applies fine and everything works as it should apart from waking up. I read in the very well written documentation that these issues appears in hybrid and legacy modes.

How can I check if the controller is running in native mode properly? As that appears to be the logical explanation as to why it doesn't wake up properly. But maybe it's something else like a BIOS setting. Thunderbolt is set to legacy mode, when set to Unique ID the same wake issue happens but the controller no longer shows up in System Information's Thunderbolt/USB 4 section. I've attached the panic log and the ACPI patches used (TbtOnPCH and OsxDetect).

Please let me know if you need anything else like IOreg, EEPROM or ACPI dumps. On my repo you can also find more stuff that might help, the default config uses a different SSDT-TbtOnPCH patch (one with the DROM inside of it), the one used after patching the firmware doesn't have it anymore. Maybe things go wrong there. I'm not really sure and by no means an expert in any of this. Merely an enthusiastic enthusiast haha.

FWIW I have a dedicated NUC for testing, in possession of a flash programmer and not afraid to use it 😅

nuc-tb3-wake-panic.txt SSDT-OsxDetect.dsl.zip SSDT-TbtOnPCH-POST.dsl.zip

[osy]

Post your IOreg dump. If you see a bunch of devices under AppleThunderboltNHIType3 then it’s running in native.

[zearp]

Thanks for the hint. Seems to be working in native mode.

[osy]

If you leave a device plugged in (usb or TB3) does this still happen?

[zearp]

With some usb devices connected it still happens. While sleeping power was cut to usb sticks (leds went off) but a usb light I also put in remained lit. Not sure if thats helpful, just an observation haha.

[osy]

Is there a BIOS option to prevent this? Can you wake from sleep with a usb keyboard connected through the port? What happens if you do it from windows?

[zearp]

I can't wake it up with a usb keyboard when connected to tb3, I can wake it up from other usb ports/power button but it still panics.

BIOS: Found an option to enable/disable usb power in s4/s5 (default disabled), enabling it didn't help. There's also an option allowing wake from Thunderbolt connected devices, default enabled. I didn't toggle it to test.

There's an option to select legacy s3 or modern stand-by. It defaults to legacy, when set to modern macOS boots and sleep work but waking up form usb keyboard connected to the tb3 port didn't do anything and when using the power button it woke up but got the same panic.

There's also an ASPM toggle, enabled by default. Untested by me. Other than those there are no Thunderbolt or usb related settings in regards to power management. There's setting for usb charging but that only applies to the yellow usb charge port.

All panics were the same, no matter what combo of bios options used.

Windows: In Windows with patch applied and modern stand-by enabled I was able to wake it up with a usb keyboard connected to tb3. With stand-by mode set to legacy I was not able and using the power button it woke up but the screen didn't come on. I assume it had crashed but didn't get any messages when I booted back into Windows and the event log didn't have anything in it either.

Modern stand-by: I compared a DSDT dumps from modern and legacy stand-by modes. The only difference are that the 16 instances of XDEP in legacy are renamed to _DEP in modern. It's peculiar that in legacy mode (with patch applied) macOS and Windows have the same wake issues and that in modern sleep mode in Windows it works is hopefully good news.

As an aside I noticed when using the modern stand-by setting in both macOS and Windows the power led went into pulsating blue mode despite me having s3 colour led configured as solid amber. It seems that setting uses something different from s3.

Do you think the DSDT difference have anything to do with this or maybe just some totally unrelated. I wouldn't mind switching from the default legacy to modern stand-by mode as it seem to work in both. It's also weird Intel allows us to change the sleep led colour but only for s3. I don't like the pulsating blue but can live with it haha.

Patch disabled: I've repeated the above tests with the patch disabled and modern stand-by enabled; macOS sleep works, wake not working with usb keyboard connected to tb3 but does wake up normally when using power button. The usb ports remain off even when devices are replugged. In Windows I can once again wake it up with the tb3 connected keyboard, usb ports work after wake.

Finally with patch disabled and stand-by set to legacy; in macOS same as above and Windows too. The led turns amber again.

I guess this isn't going to be something easy as I thought but hopefully I'm wrong 😅

This modern standby got me curious but couldn't find more than this write-up on Microsoft.

Sorry for the long write-up and thank you for your help so far, really appreciated.

[osy]

So on the HC NUC, I only had to manually power on the Ridge controller on cold boot with these ACPI methods https://github.com/osy/HaC-Mini/blob/master/ACPI/SSDT-TbtOnPCH-Boot.asl but on S3 boot, I think the BIOS or OSX resume code powers it up. This might not be true on your system for whatever reason. You can try to debug by running the _SB.PCI0.RP05._INI code from my ACPI table on S3 resume as well (_WAK) and see if that makes a difference. Alternatively you may want to patch out the panic and on resume, try to send the config sequence from a KEXT with logging to see if it works.

EDIT: wait no I am thinking of the Windows code. In “native thunderbolt” the BIOS always powered up the controller for me. Your system might just be slow. If you can, try patching the Thunderbolt KEXT and changing the wait time to be higher. You can find the wait/retry code by searching for your panic string.

[zearp]

Not sure if I can due to very limited experience with patching kexts. I don't really know what you mean with panic string. Do you mean search for any of the strings from the panic log inside the binary found in IOThunderboltFamily.kext? Last time I done something like this was with Azul frame buffer patching.

I opened the binary inside the kext up in a hex editor, looked around for wait/retry stuff and tried some searches for strings in the panic but didn't come up with anything but I might be doing it wrong and in the wrong place.

I did find a lot of people reporting this crash on MacBooks a few years ago. They all has the same panic on wake (UPSB and failure to power up tb3), the panic logs are eerily similar to this one. none of the posts had any useful info though. Mainly Apple support from posts devoid of any real detail. Apple eventually fixed it in an update. Found some hackintosh related posts with the same panics but nobody has found a solution thus far.