Ryzen 7000 Testing

[CaseySJ]

These are the key settings:

PCIDeviceInfo is all-important. It can be found by running FindSerialPort.command in the OpenCore downloaded folder (screenshot below). In my case, the full value is:

02010000 00000000 08000000 00000000 02000000 00000000 FF

 

[CaseySJ]

@ExtremeXT,

Attached are two serial debug captures of the boot process:

• FrankenMon -- boots up fully -- file name FrankenMon-Start-21-Oct-1440HRS
• Real Monterey -- hangs during boot -- file name Real Monterey 21-OCT-1445HRS

Notes:

• There is a bit of garbling in the log. I'll try using a baud rate higher than 115200
• These logs are with the standard kernel -- not the debug kernel
• I can install a KDK package later, if requested

 

[ExtremeXT]

@ExtremeXT,

Attached are two serial debug captures of the boot process:

• FrankenMon -- boots up fully -- file name FrankenMon-Start-21-Oct-1440HRS
• Real Monterey -- hangs during boot -- file name Real Monterey 21-OCT-1445HRS

Notes:

• There is a bit of garbling in the log. I'll try using a baud rate higher than 115200
• These logs are with the standard kernel -- not the debug kernel
• I can install a KDK package later, if requested

Do you have DebugEnhancer? If not, get another log with it and its 2 boot args. Make sure you have io=0xff as well.

 

[CaseySJ]

Do you have DebugEnhancer? If not, get another log with it and its 2 boot args. Make sure you have io=0xff as well.

With DebugEnhancer and the three boot args, real Monterey generates very sparse logs. I'll run another capture on this config before running a capture with DebugEnhancer on the control system (FrankenMon).

Update: Run 2 from Real Monterey with DebugEnhancer attached (CoolTerm Capture 2022-10-21-...)

(Logs are not sparse -- only the scroll back buffer in CoolTerm is sparse)

 

[svan71]

How does serial debugging aid in solving the audio issue ? Just trying to understand the process.

 

[ExtremeXT]

With DebugEnhancer and the three boot args, real Monterey generates very sparse logs. I'll run another capture on this config before running a capture with DebugEnhancer on the control system (FrankenMon).

Update: Run 2 from Real Monterey with DebugEnhancer attached (CoolTerm Capture 2022-10-21-...)

(Logs are not sparse -- only the scroll back buffer in CoolTerm is sparse)

Can you try with the debug=0x12a boot arg too?

How does serial debugging aid in solving the audio issue ? Just trying to understand the process.

We're trying to solve the PCIe issue.

 

[CaseySJ]

Can you try with the debug=0x12a boot arg too?

...

All of these captures were done with debug=0x12a as shown in screenshot #2 of this post above.

Ryzen 7000 Testing

These are the key settings: PCIDeviceInfo is all-important. It can be found by running FindSerialPort.command in the OpenCore downloaded folder (screenshot below). In my case, the full value is: 02010000 00000000 08000000 00000000 02000000 00000000 FF

forum.amd-osx.com

The full list of boot args is shown here. These were all in effect when previous two captures were done.

 

[ExtremeXT]

All of these captures were done with debug=0x12a as shown in screenshot #2 of this post above.

Ryzen 7000 Testing

These are the key settings: PCIDeviceInfo is all-important. It can be found by running FindSerialPort.command in the OpenCore downloaded folder (screenshot below). In my case, the full value is: 02010000 00000000 08000000 00000000 02000000 00000000 FF

forum.amd-osx.com

The full list of boot args is shown here. These were all in effect when previous two captures were done.
View attachment 7955

Does it still log with serial=5 or does it need serial=3?

 

[CaseySJ]

Does it still log with serial=5 or does it need serial=3?

serial=5 also works. Attached log is with that change.

• Vanilla Monterey
• serial=5
• debug=0x12a
• io=0xff
• DebugEnhancer and related boot args

Also attached is a successful boot log from FrankenMon. There's no garbled text in this log.

Next Step (later today): Install debug kernel and recapture boot log.

 

[PoMpIs]

Guys, I don't want to bother you, but it is so that you know that in the new Raptor Lake and an asus z790F gaming there is no problem with the audio nor with the PCIe, everything works... it only changes the integrated network on the board that is an i226v , and OOTB doesn't work, but I guess with Intelmausi it should work..




EDIT: Correct, the intel i226v also works OOTB, it had e1000=0 and that's why it didn't load it, it's perfect




Cheers

 

[etorix]

This was off-topic but it was the first report I've seen of Z790. Thanks!

 

[ExtremeXT]

serial=5 also works. Attached log is with that change.

• Vanilla Monterey
• serial=5
• debug=0x12a
• io=0xff
• DebugEnhancer and related boot args

Also attached is a successful boot log from FrankenMon. There's no garbled text in this log.

Next Step (later today): Install debug kernel and recapture boot log.

I compared the logs and the only notable difference I could find was this line:
Registering: ../AppleACPIPlatformExpert/IOPCIMessagedInterruptControllerAppleImage4: no options node: 19
I tried looking at the commit for IOPCIMessagedInterruptController.cpp, but the only change seems to be the Message Signaled Interrupts for Ethernet controllers... Because of this I think that it's still an MSI problem, last time we tried setting the limit to 0, which I assumed set it to no limit, but I might have been wrong. Can you try setting it to a big number like 1000?
pci-msi-limit=1000

Another weird thing is AppleACPIPlatformExpert, which might mean that the issue is actually in AppleACPIPlatform. If the MSI boot arg doesn't fix it, can you try replacing ONLY AppleACPIPlatform on a vanilla Monterey installation? Also, please send the vanilla version of Monterey's AppleACPIPlatform.

 

[CaseySJ]

Update on Debug Kernel (KDK):

• Unfortunately, this is a no-go because our Ryzen kernel patches do not work with a debug kernel

... previous lines deleted ...
02:563 00:018 AAPL: #[EB.B.SBS|SZ] 723512
02:580 00:017 AAPL: #[EB|B:SHA] <89e4888f0beff9f352d9761a265a05de99e89918>
02:595 00:015 AAPL: #[EB.WL.PWLFNV|!] Err(0x5) <- RT.GV wake-failure 7C436110-AB2A-4BBB-A880-FE41995C9F82
02:610 00:014 AAPL: #[EB.WL.DT|!] Err(0x5) <- EB.WL.PWLFNV
02:625 00:014 AAPL: #[EB.LD.LKC|SFX] <"boot\System\Library\KernelCollections\BootKernelExtensions.kc.development">
03:010 00:385 OC: Kernel patcher result 17 for kernel (Visual - _thread_unblock - Remove panic on variant TSC #1 - 12.0) - Not Found
03:294 00:284 OC: Kernel patcher result 18 for kernel (Visual - _thread_quantum_expire - Remove panic on variant TSC #2 - 12.0) - Not Found
04:554 01:260 OC: Kernel patcher result 19 for kernel (Visual - thread_invoke - Remove panic on variant TSC #3 - 12.0) - Not Found
04:606 00:052 OC: Kernel patcher result 20 for kernel (Visual - thread_invoke - Remove panic on variant TSC #4 - 12.0) - Not Found
04:658 00:052 OC: Kernel patcher result 21 for kernel (Visual - _thread_dispatch - Remove panic on variant TSC #5 - 12.0) - Not Found
04:846 00:187 AAPL: #[EB.LD.LKFS|-?] Ok(0)
04:860 00:014 AAPL: #[EB.LD.LKC|-?] Ok(0)
04:877 00:017 AAPL: #[EB|BST:REV1]
04:893 00:016 AAPL: #[EB|CSR:OUT] 0x00000FEF
04:908 00:014 AAPL: #[EB.BST.FBS|+]
04:923 00:014 AAPL: #[EB.BST.FBS|ADSZ] 0
04:937 00:014 AAPL: #[EB.BST.FBS|KSSZ] 0
04:951 00:014 AAPL: #[EB|SB:SBGMFNS] x86legacyap.im4m
04:966 00:014 AAPL: #[EB|RH:PF] usr\standalone\OS.dmg.root_hash
04:980 00:014 AAPL: #[EB|RH:MF] <"usr\\standalone\\OS.dmg.root_hash.x86legacyap.im4m">
04:996 00:015 AAPL: #[EB.LD.LF|IN] 0 1 <"usr\\standalone\\OS.dmg.root_hash"> <"0">
05:014 00:017 AAPL: #[EB.LD.LF|IN] 0 1 <"usr\\standalone\\OS.dmg.root_hash.x86legacyap.im4m"> <"0">
05:030 00:015 AAPL: #[EB.BST.FBS|RHPSZ] 229
05:044 00:014 AAPL: #[EB.BST.FBS|RHMSZ] 3627
05:058 00:014 AAPL: #[EB|LOG:DT] 2022-10-22T17:39:57
05:073 00:014 AAPL: #[EB|LOG:EXITBS:START] 2022-10-22T17:39:57

 

[CaseySJ]

I compared the logs and the only notable difference I could find was this line:
Registering: ../AppleACPIPlatformExpert/IOPCIMessagedInterruptControllerAppleImage4: no options node: 19
I tried looking at the commit for IOPCIMessagedInterruptController.cpp, but the only change seems to be the Message Signaled Interrupts for Ethernet controllers... Because of this I think that it's still an MSI problem, last time we tried setting the limit to 0, which I assumed set it to no limit, but I might have been wrong. Can you try setting it to a big number like 1000?
pci-msi-limit=1000

Another weird thing is AppleACPIPlatformExpert, which might mean that the issue is actually in AppleACPIPlatform. If the MSI boot arg doesn't fix it, can you try replacing ONLY AppleACPIPlatform on a vanilla Monterey installation? Also, please send the vanilla version of Monterey's AppleACPIPlatform.

Currently working on this. Some complications came up that are delaying my progress. Those complications have just been resolved. Should have a reply in about an hour.

 

[CaseySJ]

Okay, after sorting a few issues out:

• It was necessary to disable my USB port map in order to boot Vanilla Monterey with no PCIe devices attached
• pci-msi-limit=1000 still causes Monterey to reboot when a PCIe device is present
• I can try replacing just AppleACPIPlatform on Monterey, but I suspect it's cross-linked with IOPCIFamily

Attached is the vanilla version of AppleACPIPlatform from Monterey.

 

[CaseySJ]

** Notable Update **​

• I don't recall trying pci-msi-limit=0, so I just tried it...
• Vanilla Monterey no longer crashes when PCIe devices are present. The system boots up, but no drivers attach to PCIe devices.
• This means I can enable serial debugging and capture a full boot log.
• Will post a new capture shortly.

Update:

• Vanilla Monterey boots up if (a) Thunderbolt is disabled and (b) Verbose logs are enabled. If we change either of these settings, it will reboot during launch. However, the PCIe serial card is installed.

 

[CaseySJ]

Alas, after enabling serial port debug, Vanilla Monterey hangs/crashes despite pci-msi-limit=0. Attached is the captured boot log anyway -- to see if there's any difference.

 

[ExtremeXT]

I think it's time to make an issue on Acidanthera's bugtracker...

 

[CaseySJ]

I just updated the "Notable Update" post above...

• With the PCIe serial card installed, vanilla Monterey will boot with or without pci-msi-limit=0, but only when verbose mode is enabled
• So pci-msi-limit=0 is not affecting the ability to boot
• Not sure why verbose mode allows the system to boot
• However, if Thunderbolt is enabled, system will not boot regardless of verbose mode

 

[CaseySJ]

I think it's time to make an issue on Acidanthera's bugtracker...

We may need to be somewhat specific.

If we just say, support AMD Ryzen 7000 series on AM5, that may be too vague. They may need to know what issues we're experiencing and where we believe the problem lies.

There are two known problems:

• Garbled audio across all recent versions of macOS
• Boot loop only in Monterey and Ventura when PCIe devices are installed or enabled in BIOS
  • For this issue, I can provide serial capture logs to them