Ryzen 7000 Testing

C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 4 of N​

Conditions:
  • This is a comparison of how interrupts are set up
  • Intel platform with driver from 12.6.x that works properly because AppleVTD is enabled
  • The same number of MSI interrupts were found and registered, but here we see that each interrupt was remapped by AppleVTD
  • The log messages that look like ir[0x90] 0x0 -> 0x890003 are actually from AppleVTD::IOPCISetMSIInterrupt
  • This I believe is Interrupt Remapping, which is the primary function of DMAR (DMA Remap Table)
  • However, I don't think the driver calls this function directly; regardless, the interrupts "should" still work but it really seems that this is where the system goes off the rails
Bash: 
# alloc_rx_rings just finished as we can see by the "exit" sign <==
2022-11-27 11:41:17.697786-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::alloc_rx_rings:0x00000001

# setup_intr function now begins as we can see by the 'entry' sign ==>
2022-11-27 11:41:17.697788-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::setup_intr
2022-11-27 11:41:17.697813-0800 0x6d9  kernel: (IOPCIFamily) ir[0x89] 0x0 -> 0x890003
2022-11-27 11:41:17.697816-0800 0x6d9  kernel: (IOPCIFamily) ir[0x89] 0x0 -> 0x890003
2022-11-27 11:41:17.697818-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8a] 0x0 -> 0x8a0003
2022-11-27 11:41:17.697821-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8a] 0x0 -> 0x8a0003
2022-11-27 11:41:17.697822-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8b] 0x0 -> 0x8b0003
2022-11-27 11:41:17.697825-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8b] 0x0 -> 0x8b0003
2022-11-27 11:41:17.697826-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8c] 0x0 -> 0x8c0003
2022-11-27 11:41:17.697829-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8c] 0x0 -> 0x8c0003
2022-11-27 11:41:17.697831-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8d] 0x0 -> 0x8d0003
2022-11-27 11:41:17.697833-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8d] 0x0 -> 0x8d0003
2022-11-27 11:41:17.697835-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8e] 0x0 -> 0x8e0003
2022-11-27 11:41:17.697837-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8e] 0x0 -> 0x8e0003
2022-11-27 11:41:17.697839-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8f] 0x0 -> 0x8f0003
2022-11-27 11:41:17.697841-0800 0x6d9  kernel: (IOPCIFamily) ir[0x8f] 0x0 -> 0x8f0003
2022-11-27 11:41:17.697866-0800 0x6d9  kernel: (IOPCIFamily) setTunnelL1Enable(0x10000026c) 2->0
2022-11-27 11:41:17.697869-0800 0x6d9  kernel: (IOPCIFamily) setTunnelL1Enable(0x10000026c) 2->0
2022-11-27 11:41:17.697874-0800 0x6d9  kernel: (IOPCIFamily) setTunnelL1Enable(0x10000026c) 2->0
2022-11-27 11:41:17.697877-0800 0x6d9  kernel: (IOPCIFamily) setTunnelL1Enable(0x10000026c) 2->0
2022-11-27 11:41:17.697890-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000000, type = 0x00010000
2022-11-27 11:41:17.697919-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000001, type = 0x00010000
2022-11-27 11:41:17.697931-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000002, type = 0x00010000
2022-11-27 11:41:17.697941-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000003, type = 0x00010000
2022-11-27 11:41:17.697950-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000004, type = 0x00010000
2022-11-27 11:41:17.697961-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000005, type = 0x00010000
2022-11-27 11:41:17.697971-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - MSI Interrupt found. Line = 0x00000006, type = 0x00010000
2022-11-27 11:41:17.697990-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.697993-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.697995-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.697997-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.697999-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.698001-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered
2022-11-27 11:41:17.698003-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) setup_intr - Interrupt source registered

# success
2022-11-27 11:41:17.698005-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::setup_intr status = 0x00000001

# now the next step starts, which is initializing the hardware
2022-11-27 11:41:17.698007-0800 0x6d9  kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::init_enet_hw

Here is the function IOPCISetMSIInterrupt:

C: 
IOPCISetMSIInterrupt(uint32_t vector, uint32_t count, uint32_t * msiData)
{
    AppleVTD * vtd;
    uint64_t   present;
    uint64_t   destVector;
    uint64_t   destID;
    uint64_t   levelTrigger;
    uint64_t   irte;
    uint64_t   prior;
    uint32_t   idx;
    bool       inval;

    if (!(vtd = OSDynamicCast(AppleVTD, IOMapper::gSystem))) return (kIOReturnUnsupported);
    if (!vtd->fIRTable)                                      return (kIOReturnUnsupported);

    if ((vector + count) > kIRCount) panic("IOPCISetMSIInterrupt(%d, %d)", vector, count);

    inval = false;
    for (idx = vector; idx < (vector + count); idx++)
    {
        extern int cpu_to_lapic[];
        int destShift;

        levelTrigger = 0;
        present      = (msiData != 0);
        destVector   = (0xFF & idx);
        destID       = (uint64_t)cpu_to_lapic[((idx & 0xFF00) >> 8)];
        /* In x2APIC mode, the destination starts at bit 32; legacy xAPIC: bit 40 */
        destShift    = vtd->x2apic_mode ? 32 : 40;
        irte = (destID << destShift)      // destID
             | (destVector << 16)  // vector
             | (0 << 5)            // fixed delivery mode
             | (levelTrigger << 4) // trigger
             | (0 << 3)            // redir
             | (0 << 2)            // phys dest
             | (1 << 1)            // faults ena
             | (present << 0);       // present

        prior = vtd->fIRTable[idx].data;
        VTLOG("ir[0x%x] 0x%qx -> 0x%qx\n", idx, prior, irte);

        // msi should only be set once and removed
        if (!(1 & (prior ^ irte))) panic("msi irte 0x%qx prior 0x%qx", irte, prior);

        if (irte != prior)
        {
            vtd->fIRTable[idx].data = irte;
            __mfence();
            if (1 & prior) inval = true;
        }
    }

    if (inval) vtd->interruptInvalidate(vector, count);

    if (msiData)
    {
        /* WARNING: If x2APIC is enabled, this MUST be in remappable format! */
        msiData[0] = 0xfee00000                    // addr lo
               | ((vector & 0x7fff) << 5)    // handle[14:0]
               | (1 << 4)              // remap format
               | (1 << 3)              // SHV (add subhandle to vector)
               | ((vector & 0x8000) >> 13); // b2 handle[15]

        msiData[1] = 0;                 // addr hi
        msiData[2] = 0;                // data (subhandle)
    }

    return (kIOReturnSuccess);
}
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 5 of N​

Conditions:
  • Now let's look at head and tail pointers in the Receive Ring link list
  • This is from AMD with 12.2.x driver that works
  • We can see that head does increment
Bash: 
head = 0 tail = 0
head = 0 tail = 0
head = 0 tail = 1
head = 0 tail = 2
head = 0 tail = 3
head = 0 tail = 4
head = 0 tail = 5
head = 0 tail = 6
head = 0 tail = 7
head = 0 tail = 8
head = 0 tail = 9
head = 0 tail = 10
head = 0 tail = 11
head = 0 tail = 12
head = 0 tail = 13
head = 0 tail = 14
head = 0 tail = 15
head = 0 tail = 16
head = 0 tail = 17
head = 0 tail = 18
head = 0 tail = 19
head = 0 tail = 20
head = 0 tail = 21
head = 0 tail = 22
head = 0 tail = 23
head = 0 tail = 24
head = 0 tail = 25
head = 26 tail = 26
head = 26 tail = 27
head = 26 tail = 28
head = 26 tail = 29
head = 26 tail = 30
head = 26 tail = 31
head = 26 tail = 32
head = 26 tail = 33
head = 26 tail = 34
head = 26 tail = 35
head = 26 tail = 36
head = 26 tail = 37
head = 26 tail = 38
head = 26 tail = 39
head = 26 tail = 40
head = 26 tail = 41
head = 26 tail = 42
head = 26 tail = 43
head = 26 tail = 44
head = 26 tail = 45
head = 26 tail = 46
head = 26 tail = 47
head = 26 tail = 48
head = 26 tail = 49
head = 26 tail = 50
head = 26 tail = 51
head = 26 tail = 52
head = 26 tail = 53
head = 26 tail = 54
head = 26 tail = 55
head = 26 tail = 56
head = 26 tail = 57
head = 26 tail = 58
head = 26 tail = 59
head = 26 tail = 60
head = 26 tail = 61
head = 26 tail = 62
head = 26 tail = 63
head = 26 tail = 64
head = 26 tail = 65
head = 26 tail = 66
head = 26 tail = 67
head = 26 tail = 68
head = 26 tail = 69
head = 26 tail = 70
head = 26 tail = 71
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 6 of N​

Conditions:
  • Continuing to look at head and tail pointers in the Receive Ring link list
  • This is from AMD with 12.6.x driver that does not work
  • We can see that head just stays at 0
Bash: 
head = 0 tail = 0
head = 0 tail = 0
head = 0 tail = 1
head = 0 tail = 2
head = 0 tail = 3
head = 0 tail = 4
head = 0 tail = 5
head = 0 tail = 6
head = 0 tail = 7
head = 0 tail = 8
head = 0 tail = 9
head = 0 tail = 10
head = 0 tail = 11
head = 0 tail = 12
head = 0 tail = 13
head = 0 tail = 14
head = 0 tail = 15
head = 0 tail = 16
head = 0 tail = 17
head = 0 tail = 18
head = 0 tail = 19
head = 0 tail = 20
head = 0 tail = 21
head = 0 tail = 22
head = 0 tail = 23
head = 0 tail = 24
head = 0 tail = 25
head = 0 tail = 26
head = 0 tail = 27
head = 0 tail = 28
head = 0 tail = 29
head = 0 tail = 30
head = 0 tail = 31
head = 0 tail = 32
head = 0 tail = 33
head = 0 tail = 34
head = 0 tail = 35
head = 0 tail = 36
head = 0 tail = 37
head = 0 tail = 38
head = 0 tail = 39
head = 0 tail = 40
head = 0 tail = 41
head = 0 tail = 42
head = 0 tail = 43
head = 0 tail = 44
head = 0 tail = 45
head = 0 tail = 46
head = 0 tail = 47
head = 0 tail = 48
head = 0 tail = 49
head = 0 tail = 50
head = 0 tail = 51
head = 0 tail = 52
head = 0 tail = 53
head = 0 tail = 54
head = 0 tail = 55
head = 0 tail = 56
head = 0 tail = 57
head = 0 tail = 58
head = 0 tail = 59
head = 0 tail = 60
head = 0 tail = 61
head = 0 tail = 62
head = 0 tail = 63
head = 0 tail = 64
head = 0 tail = 65
head = 0 tail = 66
head = 0 tail = 67
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 7 of N​

Conditions:
  • Continuing to look at head and tail pointers in the Receive Ring link list
  • This is from Intel with 12.6.x driver that works because AppleVTD is available
  • We can see that head regularly increments (head and tail do not have to move together)
Bash: 
head = 0 tail = 0
head = 0 tail = 0
head = 1 tail = 1
head = 2 tail = 2
head = 3 tail = 3
head = 4 tail = 4
head = 5 tail = 5
head = 6 tail = 6
head = 7 tail = 7
head = 8 tail = 8
head = 9 tail = 9
head = 10 tail = 10
head = 11 tail = 11
head = 12 tail = 12
head = 13 tail = 13
head = 14 tail = 14
head = 15 tail = 15
head = 16 tail = 16
head = 17 tail = 17
head = 18 tail = 18
head = 19 tail = 19
head = 20 tail = 20
head = 20 tail = 21
head = 22 tail = 22
head = 23 tail = 23
head = 24 tail = 24
head = 25 tail = 25
head = 26 tail = 26
head = 27 tail = 27
head = 28 tail = 28
head = 29 tail = 29
head = 30 tail = 30
head = 31 tail = 31
head = 32 tail = 32
head = 33 tail = 33
head = 34 tail = 34
head = 35 tail = 35
head = 36 tail = 36
head = 37 tail = 37
head = 38 tail = 38
head = 39 tail = 39
head = 40 tail = 40
head = 41 tail = 41
head = 42 tail = 42
head = 43 tail = 43
head = 44 tail = 44
head = 45 tail = 45
head = 46 tail = 46
head = 47 tail = 47
head = 48 tail = 48
head = 48 tail = 49
head = 50 tail = 50
head = 51 tail = 51
head = 52 tail = 52
head = 53 tail = 53
head = 54 tail = 54
head = 55 tail = 55
head = 56 tail = 56
head = 57 tail = 57
head = 58 tail = 58
head = 59 tail = 59
head = 60 tail = 60
head = 61 tail = 61
head = 62 tail = 62
head = 63 tail = 63
head = 64 tail = 64
head = 65 tail = 65
head = 66 tail = 66
head = 67 tail = 67
head = 68 tail = 68
head = 69 tail = 69
head = 69 tail = 70
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 8 of N​

The result of all this is the realization that received packets are not being read properly.
  • Let's see how the interrupt_msi_handler should work
  • This is from 12.2.x on AMD, where the interrupt handler works properly
Bash: 
# The symbol "==>" means we're entering a function, in this case "interrupt_msi_handler"
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::interrupt_msi_handler

# The handler begins reading data
kernel: (AppleEthernetAquantiaAqtion) reg_get32(<private>, 0x00000009)

# The received data will go to the "rx_pkt_queue"
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::rx_pkt_queue
kernel: (AppleEthernetAquantiaAqtion) desc_head = 267
kernel: (AppleEthernetAquantiaAqtion) rx_desc_head = 0x0000000015980010 0x0000000000560023
kernel: (AppleEthernetAquantiaAqtion) offsetof(drop_the_rest) = 168

# We received 86 bytes *packet length", which may include packet headers and footers
kernel: (AppleEthernetAquantiaAqtion) buf_len = 86 pkt_len = 0

# because this particular buffer has been used, it needs to be replaced
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::replace_dma_buffer
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::replace_dma_buffer mbuf=<private>
kernel: (AppleEthernetAquantiaAqtion) rss_type = 0x00000000 rss_hash = 0x00000000
kernel: (AppleEthernetAquantiaAqtion) pkt_len = 86

kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x0000010b)
kernel: (AppleEthernetAquantiaAqtion) Flushing input queue.
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::rx_pkt_queue

# interrupt handler now exits
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::interrupt_msi_handler

# this looks like an "ACK" message back to the sender
kernel: (AppleEthernetAquantiaAqtion) reg_get32(<private>, 0x00000001)
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 9 of N​

  • This is from 12.6.x on AMD, where the interrupt handler does not work
  • Everything looks the same as on the working Intel system, except that all the received bytes are zero
Bash: 
# interrupt handler called
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::interrupt_msi_handler index=0

# we read the packet
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::rx_pkt_queue

# we get so far as to allocate_mbuf and copy data from DMA buffer to receive-ring buffer
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::allocate_mbuf
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::allocate_mbuf mbuf=<private>

# this is a received-packet counter; it's currently 0x0000000a or decimal 10; below we can see that it increments to 11
kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x0000000a)

# flush the input queue and exit; nothing abnormal...except that all the received data is zero!
kernel: (AppleEthernetAquantiaAqtion) Flushing input queue.

# exit the packet-read function
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::rx_pkt_queue

kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x00000001)

# exit the interrupt handler
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::interrupt_msi_handler


...NEXT PACKET ARRIVES...


# now another interrupt occurs...
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::interrupt_msi_handler index=0
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::rx_pkt_queue
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::allocate_mbuf
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::allocate_mbuf mbuf=<private>

# notice that the received-packet counter increments to 0x0000000b or decimal 11
kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x0000000b)

kernel: (AppleEthernetAquantiaAqtion) Flushing input queue.
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::rx_pkt_queue
kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x00000001)

# we return
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::rx_pkt_queue
 
Last edited:
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Log Analysis 10 of N​

  • This is from 12.6.x on Intel, where the interrupt handler works properly because AppleVTD is available
Bash: 
# interrupt handler starts
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::interrupt_msi_handler index=0

# we begin to read the packet
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::rx_pkt_queue

# we allocate a buffer for the data to be copied into from DMA buffer
kernel: (AppleEthernetAquantiaAqtion) ==> AppleEthernetAquantiaAqtion::allocate_mbuf
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::allocate_mbuf mbuf=<private>
kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x00000271)
kernel: (AppleEthernetAquantiaAqtion) Flushing input queue.

# data successfully read into buffer
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::rx_pkt_queue

# send ACK to sender
kernel: (AppleEthernetAquantiaAqtion) reg_put32(<private>, 0x00000001)

# interrupt handler exits
kernel: (AppleEthernetAquantiaAqtion) <== AppleEthernetAquantiaAqtion::interrupt_msi_handler
 
Last edited:
E

Ejh4286

Member
AMD OS X Member
Joined
Oct 30, 2021
Messages
43
CaseySJ said:
I'll reinstall my Fenvi FV-T919 shortly and test this.

The Asus X670E Gene has only one extra PCI slot and it's currently populated with an Aquantia AQC-113C.
Click to expand...
I installed a Fenvi T919 on my x670e gene and it is not recognized. Any thoughts?
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Additional Thoughts:
  • VT-d remaps both interrupts and DMA buffer addresses
  • Interrupts are occurring properly so there may instead be an issue with DMA buffer addresses
  • Aquantia controller may be writing incoming data to standard DMA buffer locations, but rx_pkt_queue may be trying to use a remapped address, which wouldn’t contain anything because addresses weren’t remapped
This is just speculation, but if Aquantia controller is in fact receiving data and storing it in a DMA address, then the driver may just be looking in the wrong place.
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Galve2000 said:
The amount of progress made in this thread in the past 2 months is nothing short of STAGGERING.

patience grass-hopper.
Click to expand...
Ethernet packets captured with WireShark confirm that transmitted packets are okay, but received ones are not. Packets are being received, but most likely the driver is looking for them in the wrong place. Will post WireShark screenshot shortly (out to lunch at the moment).
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Ejh4286 said:
I installed a Fenvi T919 on my x670e gene and it is not recognized. Any thoughts?
Click to expand...
Are you still experiencing a problem with this?
 
O

ovenlite1

Active member
AMD OS X Member
Joined
Jun 22, 2020
Messages
106
Before AM5 released I had convinced myself that I wouldn't be making the jump from my second hand AM4 system, which is amazing in its own right. However... not sure how much I can resist- an Asus X670e-I system is looking pretty sweet right about now...
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
CaseySJ said:
Ethernet packets captured with WireShark confirm that transmitted packets are okay, but received ones are not. Packets are being received, but most likely the driver is looking for them in the wrong place. Will post WireShark screenshot shortly (out to lunch at the moment).
Click to expand...
  • These are WireShark capture logs for Ethernet port en1 (my 10Gbps Aquantia)
  • These logs begin as soon as the cable is connected
  • We can see that packets are sent properly, but not received properly

This is the log from standard Monterey 12.6.x driver that does not work. We can see a bunch of packets in white that have arrived, but the packet buffers are filled with zeroes.
Screen Shot 2022-11-29 at 10.14.36 AM.png
And this is from Monterey with the driver from 12.2.x, where everything works properly. We can see that DHCP has responded and normal TCP traffic has begun (in green).
Screen Shot 2022-11-29 at 10.14.22 AM.png
 
Last edited:
B

backinblackx86

Member
AMD OS X Member
Joined
Nov 10, 2022
Messages
56
ovenlite1 said:
Before AM5 released I had convinced myself that I wouldn't be making the jump from my second hand AM4 system, which is amazing in its own right. However... not sure how much I can resist- an Asus X670e-I system is looking pretty sweet right about now...
Click to expand...
The motherboard is very solid, using it to run a stable diffusion server 24/7
 
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
** Aquantia 10Gbps Driver Patch Created and Verified **
Works in Monterey and Ventura
​

This was a tough problem made worse by not having the source code. But the disassembly files posted by @ExtremeXT were ultimately very helpful, along with my previous IOPCIFamily XCode project.

What this Means:
  • This means we do not need to disable the native AppleEthernetAquantiaAqtion driver and inject a modified version
  • This means we simply need to apply six driver patches and one boot argument
  • This works in Ventura as well
  • Will provide full details soon

First let me show the results:

Screen Shot 2022-11-29 at 3.40.44 PM.png


Here's Ventura:
Screenshot 2022-11-29 at 3.50.35 PM.png
 
Last edited:
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
** Aquantia 10Gbps Driver Patches for Non-AppleVTD Systems **​

Background:
The AppleEthernetAquantiaAqtion driver in Monterey and Ventura requires AppleVTD, which is not available on AMD platforms. Although we are able to import an older non-VTD version of the driver into Monterey, we are currently unable to do so in Ventura. The driver patches and boot argument presented here enable the native driver in both Monterey and Ventura to function properly in the absence of AppleVTD.


Description of Patches:
Refer to "Aquantia Patch Theory" by clicking here.


Procedure:
  1. Install the six Aquantia driver patches shown below
  2. Add boot argument ixgbe=0 30-Nov: Boot argument is not needed
  3. Enable the kernel quirk ForceAquantiaEthernet
  4. One time action: Perform a cold boot, which means:
    • Shutdown the computer
    • Flip power switch on PSU to OFF for 10 seconds
    • Power back up
If you applied the previous method of injecting an older version of the driver, be sure to undo those settings:
  • Uncheck or remove the injection of AppleEthernetAquantiaAqtion.kext from Kernel --> Add
  • Uncheck or remove the blockage of AppleEthernetAquantiaAqtion from Kernel --> Block

Aquantia Driver Patches:
All six of these patches are required. The same patches work in both Monterey 12.6.x and Ventura (any version).

Patch 1: Receive Ring Patch 1
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion13alloc_rx_ringEj
  • Comment: CaseySJ - Fix alloc_rx_ring #1
  • Find: 4C89EF41 B8030000 00
  • Replace: 4C89EF41 B8130000 00
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Patch 2: Receive Ring Patch 2
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion13alloc_rx_ringEj
  • Comment: CaseySJ - Fix alloc_rx_ring #2
  • Find: BA001000 00BF0100 0000
  • Replace: BA001000 00BF1100 0000
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Patch 3: Transmit Ring Patch 1
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion13alloc_tx_ringEj
  • Comment: CaseySJ - Fix alloc_tx_ring #1
  • Find: 4C89E741 B8030000 00
  • Replace: 4C89E741 B8130000 00
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Patch 4: Transmit Ring Patch 2
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion13alloc_tx_ringEj
  • Comment: CaseySJ - Fix alloc_tx_ring #2
  • Find: BA001000 00BF0200 0000
  • Replace: BA001000 00BF1200 0000
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Patch 5: Allocate AVB Packet
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion14allocAvbPacketEj
  • Comment: CaseySJ - Fix allocAvbPacket
  • Find: 4C89F741 B8030000 00
  • Replace: 4C89F741 B8130000 00
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Patch 6: Allocate PTP Packet
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Base: __ZN27AppleEthernetAquantiaAqtion14allocPtpPacketEj
  • Comment: CaseySJ - Fix allocPtpPacket
  • Find: BA000200 00BF0300 0000
  • Replace: BA000200 00BF1300 0000
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 1
  • Enabled: True
Screen Shot 2022-11-30 at 3.54.00 AM.png
1-Dec-2022: Compact Kernel Patches:

We can make use of OpenCore's Mask and ReplaceMask features to reduce the number of Aquantia driver patches to merely two. The compact driver patches are as follows:

Patch 1: Fix alloc_dma_buffer
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Comment: CaseySJ - Fix alloc_dma_buffer
  • Find: 4C89E741 B8030000 00
  • Replace: 4C89F741 B8130000 00
  • Mask: FFFFE7FF FFFFFFFF FF
  • ReplaceMask: 00000000 00100000 00
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 3
  • Enabled: True
Patch 2: Fix IOBufferMemoryDescriptor::withOptions
  • Arch: x86_64
  • Identifier: com.apple.driver.AppleEthernetAquantiaAqtion
  • Comment: CaseySJ - Fix IOBufferMemoryDescriptor::withOptions
  • Find: BA000000 00BF0000 0000
  • Replace: BA000200 00BF1300 0000
  • Mask: FFFF00FF FFFFF0FF FFFF
  • ReplaceMask: 00000000 00001000 0000
  • MinKernel: 21.0.0
  • MaxKernel: 22.99.99
  • Count: 3
  • Enabled: True
 
Last edited:
C

CaseySJ

Guru
Guru
Donator
Joined
May 10, 2020
Messages
1,265
Potential Issue with Aquantia Patch:
  • If you are able to test the Aquantia patch, please check if the 10Gbps port wakes up properly from sleep
Update 30 Nov 2022:
After applying all six patches, the port resumes properly from sleep (i.e., no problem waking from sleep)
 
Last edited:
G

Galve2000

Donator
Donator
AMD OS X Member
Joined
Sep 19, 2020
Messages
234
CaseySJ said:
ll four of these patches are required. The same patches work in both Monterey 12.6.x and Ventura (any version).
Click to expand...

Where does one find these kernel patches?

I want to try this on my X570/5950X system.
 
You must log in or register to reply here.

Online statistics

Members online
1
Guests online
503
Total visitors
504
Totals may include hidden visitors.

Latest posts

Useful Links

Share this page

Back
Top Bottom
✖
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.