Ryzen 7000 Testing

[mariettosun]

Here, but unfortunately it's not open source.

they are trying t solve also a problem with i210 board but if you ask they are kind and happy to answer

 

[ExtremeXT]

they are trying t solve also a problem with i210 board but if you ask they are kind and happy to answer

Doesn't I210 work with Apple's AppleIntelI210Ethernet.kext? It's even in the name... If it doesn't, maybe we can investigate and try patching it.

 

[CaseySJ]

Here, but unfortunately it's not open source.

they are trying t solve also a problem with i210 board but if you ask they are kind and happy to answer

I have a Gigabyte B550 Vision D with Ryzen 7 3700x so now I am tempted to upgrade that to Ryzen 5 5600X and install my AQC-107. Also want to fix the two on-board Intel i211 ports.

 

[CaseySJ]

Doesn't I210 work with Apple's AppleIntelI210Ethernet.kext? It's even in the name... If it doesn't, maybe we can investigate and try patching it.

The thought had occurred to me! Because it requires AppleVTD, perhaps we can apply the same technique.

Update:

• In Monterey and Ventura the i211 is driven by DriverKit
• If we use e1000=0 to disable DriverKit, there is no fallback driver unless we inject one from Big Sur
• Can we patch a DriverKit driver? Not sure OpenCore can do that.

 

[mariettosun]

Doesn't I210 work with Apple's AppleIntelI210Ethernet.kext? It's even in the name... If it doesn't, maybe we can investigate and try patching it.

on TRX40 Designare (gigabyte) it seems it does not work

 

[mariettosun]

@Arrakis users is also here
maybe he could try

 

[CaseySJ]

on TRX40 Designare (gigabyte) it seems it does not work

Correct — even on B550 it does not work. Causes system crash when cable is connected.

 

[mariettosun]

Correct — even on B550 it does not work. Causes system crash when cable is connected.

dev has passed that problem
now connect is there but no surfing in the net

 

[mariettosun]

@CaseySJ here is the thread with some logs

GIGABYTE TRX40 DESIGNARE (RÉV. 1.1) / AMD Ryzen Threadripper 3960 X

www.macos86.it

 

[etorix]

If the patches cannot be further trimmed, should them get PR-ed to be merged into the ForceAquantiaEthernet kernel quirk in OC?

Wouldn't that cause issues for Intel systems where Aquantia NIC work with the current quirk (spoofing?) and AppleVTD enabled, if this case occurs?
The patches potentially apply to all AMD systems and to Intel systems without AppleVTD. A new quirk, to be activated independently of ForceAquantiaEthernet, may be more appropriate.
Also, ideally, the new quirk would also silently enforce the boot-argument 'ixgbe=0'. @CaseySJ , what is the relevance of this boot argument? If I decipher correctly that it relates to "Intel (Roman) ten gigabyte ethernet" its use with a non-Intel NIC is puzzling.

 

[mariettosun]

ixgbe=0

@etorix on my rig I do not use that bootarg, I use only the six patches posted by Casey in this thread

 

[CaseySJ]

Wouldn't that cause issues for Intel systems where Aquantia NIC work with the current quirk (spoofing?) and AppleVTD enabled, if this case occurs?
The patches potentially apply to all AMD systems and to Intel systems without AppleVTD. A new quirk, to be activated independently of ForceAquantiaEthernet, may be more appropriate.

A separate quirk makes sense.

Also, ideally, the new quirk would also silently enforce the boot-argument 'ixgbe=0'.

Correct. The quirk should apply this boot argument. Update: boot arg is not be needed, per @mariettosun

@CaseySJ , what is the relevance of this boot argument?

This disables the DriverKit Extension (DEXT) for 10GbE devices. The dext can either provide full driver functionality (which means fully replacing an existing driver) or provide supplementary functionality to an existing driver. For the latter case, the dext achieves this by by sub-classing the kext. In other words, it uses C++ object inheritance to create a new parent dext class derived from the original kext class.

The parent class does “bad things” (that’s the technical term for it) so even with the patches, the Aquantia port fails to work. Update: boot arg is not be needed

If I decipher correctly that it relates to "Intel (Roman) ten gigabyte ethernet" its use with a non-Intel NIC is puzzling.

Yes the name is puzzling, but this driver does in fact support Intel X550 and possibly other series of 10GbE devices.

 

[mariettosun]

@CaseySJ is it mandatory for you to use the bootarg together with quirk and your six patches?

 

[CaseySJ]

@CaseySJ is it mandatory for you to use the bootarg together with quirk and your six patches?

I remember trying it today without the boot argument, but the port could not sense cable connection.

Does it work for you without the boot argument?

 

[mariettosun]

yes I am not using, now I try to clear my nvram but I have only e1000 I use for i211 /not working in Monterey kext I am using)

 

[CaseySJ]

yes I am not using, now I try to clear my nvram but I have only e1000 I use for i211 /not working in Monterey kext I am using)

If you don’t use the ixgbe boot argument, can you please post screenshot of System Information —> Ethernet with the Aquantia selected?

 

[mariettosun]

If you don’t use the ixgbe boot argument, can you please post screenshot of System Information —> Ethernet with the Aquantia selected?

do you mean this?

 

[CaseySJ]

do you mean this?


View attachment 8846

OMG, so it does work without the boot argument -- and AVB is also enabled!

You can see in my screenshot posted earlier today that AVB is disabled.

I'll re-check this later today.

Ryzen 7000 Testing

I hope I am not wrong here 😅

forum.amd-osx.com

 

[mariettosun]

Saturday at 2:28 AM

also this user has a "107" and AVB is active ( I dont know if @DarkSilentSC tested in his system without boot arg

 

[CaseySJ]

** Aquantia Patch Theory **
How the patch works / what the patch does​

Summary of Thought Process that Led to the Finding:

• Aquantia debug logs enabled by boot argument apple-axge-debug=0x1 revealed an excess number of receive ring buffers being allocated, and an excess number of AVB buffers being allocated by the ::start function
• This in itself may be harmless, but it pointed us to the alloc_rx_ring function
• Debug logs also showed normal transmit activity, but abnormal receive activity
• Subsequent examination of WireShark network-capture logs verified that packet-transmission was working properly
• Incoming packets, however, were variable sized, but all bytes were set to zero
• Because received packets were variable sized, it suggested that real data was being received but something was preventing the buffers from being read properly
• Attention returned to the alloc_rx_ring function, which is one of a handful of functions that allocates memory buffers
• These memory buffers are no ordinary buffers that we can simply allocate with malloc from the Standard C/C++ library
• Instead, these are special IOBufferMemoryDescriptor class objects that are defined and handled by the macOS kernel
• To allocate memory for kernel extensions (or kexts), IOBufferMemoryDescriptor provides several functions that allocate memory in different ways for different purposes
• So it became apparent that this class should be investigated further to see why the driver was unable to read data from these buffers

How the Patch Works / What it Does:

• The Aquantia driver configures memory using the IOBufferMemoryDescriptor::withOptions(...) function
• These 'options' dictate a number of very critical features of the memory buffer:
  • The options dictate the direction of access: whether memory will be writeable only, readable only, or both writeable and readable
  • The options also dictate whether the memory will be assigned to a physical address, a virtual address, or MACH UPL
• The working Aquantia driver from Monterey 12.2 and earlier always allocates memory using two of the available options:
  • It specifies direction (kIODirectionIn, kIODirectionOut, kIODirectionInOut)
    • These are specified in the lowest nibble of the IOOptionBits bit flag (a nibble is 4 bits)
    • 0001 = (0x1) direction is In
    • 0010 = (0x2) direction is Out
    • 0011 = (0x3) direction is In or Out
  • It specifies virtual addresses (kIOMemoryTypeVirtual)
    • This is specified in the next nibble of the flag
    • 0001 = (0x1) is virtual address
    • 0010 = (0x2) is physical address
    • 0011 = (0x3) is MACH UPL
  • For receive buffers, the working Aquantia driver uses the memory allocation flag: 0x13
    • This means:
      • 1 = virtual address
      • 3 = direction In or Out
  • For transmit buffers, the working Aquantia driver uses the memory allocation flag: 0x12
    • This means:
      • 1 = virtual address
      • 2 = direction Out
• The non-working Aquantia driver from Monterey 12.3 and onwards, however, switched the Address Type field from 1 (virtual address) to 0 (which is not defined in the header file I have)
  • Hence, the non-working driver uses the following memory allocation flags:
    • For receive buffers, it uses 0x03
      • This means:
        • 0 = what-kind-of-address-is-this? DMA remapped address?
        • 3 = direction In or Out
    • For transmit buffers, it uses 0x02
      • This means:
        • 0 = what-kind-of-address-is-this? DMA remapped address?
        • 2 = direction Out

Based on the foregoing, it is easy to see what the six patches do. They simply change the memory allocation bit flags back to address-type 1 for Virtual Address, which is identical to the previous Aquantia driver.

The six patches affect the following functions:

1. alloc_rx_ring (general purpose receive ring buffers)
2. alloc_tx_ring (general purpose transmit ring buffers)
3. allocAvbPacket (AVB = audio video bridging buffers)
4. allocPtpPacket (PTP = peer to peer packet buffers)