Ryzen 7000 Testing

[CaseySJ]

Awesome! Will give it a try shortly.

BIOS 0801 does indeed have the ability to disable iGPU, but alas it does not fix audio stuttering.

 

[CaseySJ]

Incidentally, we get this log early in the boot process:

kernel: (AppleRTC) RTC: Only single RAM bank (128 bytes)
kernel: (AppleRTC) RTC: Only single RAM bank (128 bytes)
kernel: (AppleRTC) RTC: lost battery power - time may be invalid
kernel: (AppleRTC) RTC: lost battery power - time may be invalid

But a few lines later the system is able to get the time of day:

kernel: (AppleACPIPlatform)  found RTC service
kernel: (AppleRTC) RTC: getGMTTimeOfDay 1666641484
kernel: clock_initialize_calendar system does not have monotonic clock

Not sure if this offers anything of value, but the logs on my Intel hacks do not have lost battery power - time may be invalid.

 

[ExtremeXT]

Incidentally, we get this log early in the boot process:

kernel: (AppleRTC) RTC: Only single RAM bank (128 bytes)
kernel: (AppleRTC) RTC: Only single RAM bank (128 bytes)
kernel: (AppleRTC) RTC: lost battery power - time may be invalid
kernel: (AppleRTC) RTC: lost battery power - time may be invalid

But a few lines later the system is able to get the time of day:

kernel: (AppleACPIPlatform)  found RTC service
kernel: (AppleRTC) RTC: getGMTTimeOfDay 1666641484
kernel: clock_initialize_calendar system does not have monotonic clock

Not sure if this offers anything of value, but the logs on my Intel hacks do not have lost battery power - time may be invalid.

Could you try on another AMD system if you have any?

 

[CaseySJ]

Could you try on another AMD system if you have any?

False alarm!

The same log messages appear on my AMD B550 with Ryzen 7 3700X. But this system has no issues with audio or PCIe. This is being posted from the B550 running Ventura.

 

[CaseySJ]

** Audio Update: Line Out Miracle **​

BIOS 0801 (pre-release) has made a ginormous improvement to audio from the rear Line Out and front panel audio jacks. With iGPU enabled or disabled in BIOS, or with iGPU enabled or disabled via SSDT, Line Out is now performing just as well as HDMI/DP.

This means Line Out has improved from total incomprehensible garbage to just staticky. If we enable SpeedKeeper, Line Out becomes nearly flawless.

If you go back a few pages in this thread, you'll see that we ranked Line Out worst of all. It was completely incomprehensible -- what came out of it resembled nothing like an audio stream. And now it's just as good as other audio outputs. Again, SpeedKeeper is necessary for best results.

 

[svan71]

** Audio Update: Line Out Miracle **​

It's really encouraging to hear these bios updates making such a big difference. If only we had some people on the inside who worked on them.

 

[CaseySJ]

It's really encouraging to hear these bios updates making such a big difference. If only we had some people on the inside who worked on them.

I can post an issue/bug on the Asus X670 forum where it’s likely to get the attention of Asus tech support. But first we need a valid bug description. I don’t think we can say, my Hackintosh isn’t working!

 

[CaseySJ]

Shamino (Asus employee) has posted BIOS 0803. These are pre-QC versions, which means they haven't been quality-tested. Nevertheless, I'm glad that we have access to early versions. I haven't downloaded this yet.

X670 resource

ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options to disable cores ccd go here and choose ccd xx bit map down core. each ones stand for an enabled core best to disable from the back, ie: 110000 instead of 0011000 after...

rog.asus.com

 

[fabiosun]

I don’t think we can say, my Hackintosh isn’t working

check this my conversation with AsRock tech some years ago
they know sometime the use we didd with our pc..and sometimes they give some help
Asrock from my request unlock all they bios (MSR)

 

[CaseySJ]

check this my conversation with AsRock tech some years ago
they know sometime the use we didd with our pc..and sometimes they give some help
Asrock from my request unlock all they bios (MSR)

Interesting! In this case, however, you asked them for something specific -- namely, ability to unlock MSR 0xE2. But in our case, what shall we ask Asus to do?

Our problem is that we don't know what is the problem!

We only know the symptom, and I don't think we can expect Asus technicians to troubleshoot macOS kernel issues for us!

 

[ExtremeXT]

Interesting! In this case, however, you asked them for something specific -- namely, ability to unlock MSR 0xE2. But in our case, what shall we ask Asus to do?

Our problem is that we don't know what is the problem!

We only know the symptom, and I don't think we can expect Asus technicians to troubleshoot macOS kernel issues for us!

My guess is that it's related to PCIe lane routing, but I have no proof of that... Did you try the new BIOS version?

 

[fabiosun]

Interesting! In this case, however, you asked them for something specific -- namely, ability to unlock MSR 0xE2. But in our case, what shall we ask Asus to do?

in that time pikeralpha helped me to ask right stuff
And Asrock Dev team was very kind
They also sent me a couple of bios recovery chip..just in case I did some disasters (at their expenses from Holland)
Never had an assistance in IT like the ASROCK team one

 

[CaseySJ]

My guess is that it's related to PCIe lane routing, but I have no proof of that... Did you try the new BIOS version?

• Regarding PCIe lane routing, we know that Big Sur handles this properly, but not Monterey and newer.
• Regarding the newer BIOS, I flashed 0803 about an hour ago. It behaves the same as 0801 with respect to audio and PCIe lanes.

If we only knew what to ask Asus to fix!

I can reach out to joevt, who seems quite knowledgeable about PCIe, macOS kernel, and Hackintosh. If the problem is PCIe-related (IOPCIFamily) -- as it appears to be -- perhaps Joe can point us in the right direction.

 

[CaseySJ]

** Interim Update **

I've messaged joevt on tonymac, but he hasn't posted there since early June. Let's wait a bit longer.

Meanwhile, attached are brand new serial debug logs from VanillaMon and FrankenMon. By turning off logging to disk and screen, I think there's a bit more detail captured in the serial logs.

 

[CaseySJ]

** Interim Update #2 **

Decided to capture serial debug logs from a fully working AMD Ryzen 7 3700X on Gigabyte B550 Vision D running vanilla Monterey 12.6.1. There is some garbled text around the TSC Sync log entries. We see this garbling in every debug log we've captured thus far.

Not sure if this log helps, but this system has no audio issues and no PCIe issues.

 

[CaseySJ]

Incidentally:

• Gigabyte B550 Vision D with Ryzen 7 3700X:
  • StarTech RS232 card is detected in IOReg, but no driver attaches to it in either Big Sur or Monterey
  • Serial debugging still works because UEFI driver is in charge
• Asus Crosshair X670E Gene with Ryzen 7 7700X:
  • StarTech RS232 card is detected and driver attaches to it in Big Sur and FrankenMon

Go figure...

 

[CaseySJ]

** Interim Update #3 **

Spent most of the day looking at IOPCIFamily source code, AirportBrcmNIC disassembly (Hopper app), AppleIntelI210Ethernet disassembly, and new system logs -- without serial port debugging. Goal was to see if any insight can be gained regarding PCIe failure.

Some preliminary findings:

• With only a Broadcom 94360CD WiFi/BT card and built-in I-225V Ethernet port activated, I followed the kernel initialization sequence for these devices.
• On vanilla Monterey, a driver does not attach to either device so let's see what the logs show:
• I-225V:
  • kernel: I225(0x10000027b): matching deferred by AppleIntelI210Ethernet
  • kernel: (AppleIntelI210Ethernet) AppleIntelI210::start - Built Aug 22 2022 20:16:06, fMapper 0x0
  • kernel: (AppleIntelI210Ethernet) start: NVM Checksum incorrect
  • kernel: (AppleIntelI210Ethernet) 0x0, 0x0 AppleIntelI210::start - Allocate interrupt event source failed
• Broadcom WiFi:
  • kernel: (IO80211FamilyLegacy) AirPort_BrcmNIC::init IO80211Legacy_kexts-37 "IO80211Legacy_kexts-37" Aug 22 2022 20:16:17
  • kernel: (AirPortBrcmNIC) ARPT: 19.473747: AirPort_Brcm43XX probe:, this[0xfe010a47f7936527] score[1400]
  • kernel: (AirPortBrcmNIC) ARPT: 20.234447: AirPort_Brcm43XX::start: Failed PCIe configuration, this[0xfe010a47f7936527] vendor[0x000014e4] device[0x000043a0], chip: vid[0xffff] did[0xffff] bar0[0xffffffff]

Tracing the kexts via Hopper disassembler shows the following:

• I-225V:
  • "NVM Checksum incorrect" occurs the the middle of AppleIntel210Ethernet::start() function

• Broadcom WiFi:
  • "Failed PCIe configuration" happens probably because Chip vid (vendor ID), did (device ID), and bar (base address register) are all invalid (0xff)
  • The code sequence for this is shown here, early in the start function:

Thoughts:

• It seems as if these PCIe devices were initialized earlier in the boot process because their Device and Vendor IDs were obtained properly by scanning the PCI bus.
• But a subsequent attempt to read their PCI properties (device ID, vendor ID, BAR, checksum) results in 0xff, which means the device has either been (a) reset / shutdown, or (b) the PCI addresses that point to these devices have become invalid in macOS. Of course there can be other explanations.

We know that using IOPCIFamily and AppleACPIPlatform from Big Sur avoids these problems on AM5. The theory is that:

• IOPCIFamily scans and finds all PCIe devices -- otherwise the kernel would not even attempt to match those devices to their drivers
• Kernel matches devices to drivers and calls the start() function of each driver
• The start() function attempts to validate the device by querying its PCI properties directly
• The query results in bogus values, indicating that the device has gone down or the base address pointer is not valid
• We know that this does not happen on AM4
• So it's only the combination of AM5 and Monterey IOPCIFamily that is causing the problem
• One of the principal changes made to IOPCIFamily concerns AppleVTD, but there may also be changes related to latest PCI spec

 

[CaseySJ]

** Interim Update #4 **

Using the boot argument pci=0x03 enables detailed IOPCIFamily logging in both system log and dmesg. Attached are dmesg logs from both VanillaMon and FrankenMon. System configuration is currently as follows:

• Intel WiFi enabled and AirportItlwm enabled
• Broadcom WiFi/BT card removed
• Thunderbolt disabled

I've also modified AirportItlwm and recompiled it to show a few extra logs.

First observation from the dmesg comparison is that PCI interrupts are not resolved in Vanilla Mon for a host of devices. Interrupts are, however, resolved for all USB controllers (XHC devices). This points to the MSI (Message System Interrupt) issue that was brought up earlier in this thread.

Every device that experiences a resolved interrupt failure gets marked Inactive. Hence, any further attempt to read or write to its configuration registers results in 0xff (or decimal -1).



For the Intel WiFi device, we see this on Vanilla Monterey: The devId is 0xFFFF or -1 because the device has been marked InActive. To get the devId the AirportItlwm code uses this code:

UInt16 IOPCIDevice::configRead16( UInt8 offset )
{
    if (!configAccess(false)) return (0xFFFF);
    return (parent->configRead16(space, offset));
}

The configAccess function returns false, hence configRead16 just returns 0xFFFF.

But on FrankenMon (with IOPCIFamily from Big Sur), we have no problem. The device ID is read and reported as Wi-Fi 6 AX210.

More soon...

 

[ExtremeXT]

** Interim Update #4 **

Using the boot argument pci=0x03 enables detailed IOPCIFamily logging in both system log and dmesg. Attached are dmesg logs from both VanillaMon and FrankenMon. System configuration is currently as follows:

• Intel WiFi enabled and AirportItlwm enabled
• Broadcom WiFi/BT card removed
• Thunderbolt disabled

I've also modified AirportItlwm and recompiled it to show a few extra logs.

First observation from the dmesg comparison is that PCI interrupts are not resolved in Vanilla Mon for a host of devices. Interrupts are, however, resolved for all USB controllers (XHC devices). This points to the MSI (Message System Interrupt) issue that was brought up earlier in this thread.

Every device that experiences a resolved interrupt failure gets marked Inactive. Hence, any further attempt to read or write to its configuration registers results in 0xff (or decimal -1).

View attachment 8081

For the Intel WiFi device, we see this on Vanilla Monterey: The devId is 0xFFFF or -1 because the device has been marked InActive. To get the devId the AirportItlwm code uses this code:

UInt16 IOPCIDevice::configRead16( UInt8 offset )
{
    if (!configAccess(false)) return (0xFFFF);
    return (parent->configRead16(space, offset));
}

The configAccess function returns false, hence configRead16 just returns 0xFFFF.
View attachment 8082
But on FrankenMon (with IOPCIFamily from Big Sur), we have no problem. The device ID is read and reported as Wi-Fi 6 AX210.
View attachment 8083
More soon...

Good find on the boot arg! Can you check if anything changes if you add the boot arg pci-msi-limit=0? If not, try setting it to a high number like before. If it doesn't work, maybe something like this RTL8111 commit would? We could try making a kext that automatically polls interrupts for every PCIe device...

 

[CaseySJ]

Good find on the boot arg! Can you check if anything changes if you add the boot arg pci-msi-limit=0? If not, try setting it to a high number like before. If it doesn't work, maybe something like this RTL8111 commit would? We could try making a kext that automatically polls interrupts for every PCIe device...

IOPCIConfigurator.h defines all of these flags that govern the behavior of IOPCIFamily. The value 0x03 is the combination of the first two. Any combination of these flags can be passed in as one of two boot-arguments:

• pci=0x____
  • This paramter enables the specified features
• npci=0x____
  • This parameter disables the specified features

Will try pci-msi-limit now.

enum {
    kIOPCIConfiguratorIOLog          = 0x00000001,
    kIOPCIConfiguratorKPrintf        = 0x00000002,
    kIOPCIConfiguratorVTLog          = 0x00000004,
    
    kIOPCIConfiguratorAER            = 0x00000008,
    kIOPCIConfiguratorWakeToOff      = 0x00000010,       // deprecated rdar://problem/64949845
    kIOPCIConfiguratorDeviceMap      = 0x00000020,

    kIOPCIConfiguratorLogSaveRestore = 0x00000040,
    kIOPCIConfiguratorMapInterrupts  = 0x00000080,
    kIOPCIConfiguratorPanicOnFault   = 0x00000100, 
    kIOPCIConfiguratorNoL1           = 0x00000200,           // disable L1 on thunderbolt

    kIOPCIConfiguratorDeepIdle       = 0x00000400,
    kIOPCIConfiguratorNoTB           = 0x00000800,
    kIOPCIConfiguratorTBMSIEnable    = 0x00001000,

    kIOPCIConfiguratorPFM64          = 0x00002000,
    kIOPCIConfiguratorBoot             = 0x00004000,
    kIOPCIConfiguratorIGIsMapped     = 0x00008000,
    kIOPCIConfiguratorFPBEnable      = 0x00010000,
//    kIOPCIConfiguratorAllocate       = 0x00020000,
    kIOPCIConfiguratorUsePause       = 0x00040000,

    kIOPCIConfiguratorCheckTunnel    = 0x00080000,
    kIOPCIConfiguratorNoTunnelDrv    = 0x00100000,
    kIOPCIConfiguratorNoTerminate    = 0x00200000,
    kIOPCIConfiguratorDeferHotPlug   = 0x00400000,
    kIOPCIConfiguratorNoACS          = 0x00800000,

    kIOPCIConfiguratorTBPanics       = 0x01000000,
    kIOPCIConfiguratorTBUSBCPanics   = 0x02000000,

    kIOPCIConfiguratorSystemMap      = 0x04000000,  // Force all devices to use system mapper, x86 only

    kIOPCIConfiguratorDefaultETF     = 0x08000000, // Use default extended tag settings

    kIOPCIConfiguratorBootDefer      = kIOPCIConfiguratorDeferHotPlug | kIOPCIConfiguratorBoot,
};