same screen nothing is happening even after using -v argument in clover. trying to reinstall it from scratch and i hope this time its work will update after reinstalling
Hi @mango1122
in case of you have XHC2 (under DSB2) shared with XHC (main USB), you have to do same test as @CaseySJHere with Results Here
Also, you confirm that your motherboard is ASRock Z390 Phantom ?
I tried the test and doesn't look like I need it - which is good news and bad.
Bad because the port does not detect any USBC device plugged in (which is a battle for another day and another thread).
I am waiting for a TB dock to test functionality.
Thank you being patient with me.
I tried the test and doesn't look like I need it - which is good news and bad.
Bad because the port does not detect any USBC device plugged in (which is a battle for another day and another thread).
I am waiting for a TB dock to test functionality.
Thank you being patient with me.
Hi @CaseySJ
Nice to view NHI0 and NH00 for full thunderbolt tree !
About XHC2, I have same result with normal operating of USB3.1Gen2 like you can see on my previous Log (Plug/Unplug)
On your ACPIDebug log, you have the following lines :
...
2020-01-28 18:32:13.910205-0800 localhost kernel[0]: (kernel) ACPIDebug: "PCED UPSB- Wait for config space..."
2020-01-28 18:32:12.434094-0800 localhost kernel[0]: (kernel) ACPIDebug: "PCED XHC2- Wait for config space..."
...
I don't really understand ! All ACPI Debug begin at :
2020-01-28 18:32:13.834288-0800 localhost kernel[0]: (kernel) ACPIDebug: Version 0.1.4 starting on OS X Darwin 19.2.
...the UPSB.PCED method did not work properly. This method seemed to hang inside this section:
The while ((Timer <= Local5)) loop would never exit when ICMB was modified with extra logging information. As a result, UPSB would hang. I would see PCED UPSB- Wait for config space, but I would not see UPSB PCED- Read VID/DID? So it hanged inside the Timer loop. Because of hanged UPSB, GPE _E17 was not issued, but I could mount and unmount USB 3.1 flash disks easily and reliably every time. No crash with hot plug of either USB-C or TB3 device. But TB3 devices of course would not work.
After removing all the extra logging lines from ICMB, it "seems" that the full TNODE/TBUS is trying to activate when a TB device is connected at boot, but macOS GUI hangs about 5 seconds after logging in. Nevertheless, we can see extract the system logs using Terminal. Those ACPI logs are more comprehensive now, in the spoiler below.
Because I'm curious about this, I will add one log line back at a time into ICMB and see which specific log line causes the freeze -- or whether this is or is not reproducible. If it is reproducible, I wonder if \RMDT.P1() logging might be interfering with Thunderbolt, but that remains to be seen.
The entire system log (processID == 0) is attached, but does not seem to reveal anything related to the hang.
The while ((Timer <= Local5)) loop would never exit when ICMB was modified with extra logging information. As a result, UPSB would hang. I would see PCED UPSB- Wait for config space, but I would not see UPSB PCED- Read VID/DID? So it hanged inside the Timer loop. Because of hanged UPSB, GPE _E17 was not issued, but I could mount and unmount USB 3.1 flash disks easily and reliably every time. No crash with hot plug of either USB-C or TB3 device. But TB3 devices of course would not work.
After removing all the extra logging lines from ICMB, it "seems" that the full TNODE/TBUS is trying to activate when a TB device is connected at boot, but macOS GUI hangs about 5 seconds after logging in. Nevertheless, we can see extract the system logs using Terminal. Those ACPI logs are more comprehensive now, in the spoiler below.
Because I'm curious about this, I will add one log line back at a time into ICMB and see which specific log line causes the freeze -- or whether this is or is not reproducible. If it is reproducible, I wonder if \RMDT.P1() logging might be interfering with Thunderbolt, but that remains to be seen.
Appreciate it !
About timing, probably due to by ACPIDebug process which isn't suitable.
Unfortunately, I don't know another Debug method. On last MacPro7,1 DSDT, we can find for exemple :
Debug = "EC Wake reason ="
It will be good if we can use a file or a boot arg to displays this king of informations. Probably most suitable and reliable !
For now, you can try removing all debug calling in a critical methods like PCED (when we have timing limit) and let only VID/DID display after timing in order to have few log .
I am getting no signal screen even after doing the fresh install and nothing is happening just getting no signal even after using -v argument while booting seems to be like still an issue with rx580 one. But yes I can boot with bootable usb and even if I choose to boot from catalina ssd I can get the screen. But if boot directly from ssd getting no signal screen every time. Sharing the screen shot for the same
The while ((Timer <= Local5)) loop would never exit when ICMB was modified with extra logging information. As a result, UPSB would hang. I would see PCED UPSB- Wait for config space, but I would not see UPSB PCED- Read VID/DID? So it hanged inside the Timer loop. Because of hanged UPSB, GPE _E17 was not issued, but I could mount and unmount USB 3.1 flash disks easily and reliably every time. No crash with hot plug of either USB-C or TB3 device. But TB3 devices of course would not work.
After removing all the extra logging lines from ICMB, it "seems" that the full TNODE/TBUS is trying to activate when a TB device is connected at boot, but macOS GUI hangs about 5 seconds after logging in. Nevertheless, we can see extract the system logs using Terminal. Those ACPI logs are more comprehensive now, in the spoiler below.
Because I'm curious about this, I will add one log line back at a time into ICMB and see which specific log line causes the freeze -- or whether this is or is not reproducible. If it is reproducible, I wonder if \RMDT.P1() logging might be interfering with Thunderbolt, but that remains to be seen.
The entire system log (processID == 0) is attached, but does not seem to reveal anything related to the hang.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
