TCP: BufferAllocation1 does not work with SMP kernel and Zynq port

[mike919192]

@tony-josi-aws

Is it crashing, or are you not able to send or receive packets? If it’s crashing, are you able to get the call stack/logs?

I did not observe any crash or asserts. I did include the debug messages in the zip, but I will put them in this post.

FreeRTOS_AddEndPoint: MAC: 00-11 IPv4: c0a8150aip
prvIPTask started
XEmacPs detect_phy: PHY detected at address 0.
Start PHY autonegotiation
Waiting for PHY to complete autonegotiation.
autonegotiation complete
link speed: 1000
prvEMACHandlerTask[ 0 ] started running
Network buffers: 64 lowest 64
Socket 6000 -> [0.0.0.0]:0 State eCLOSED->eTCP_LISTEN
Network buffers: 61 lowest 61
Network buffers: 60 lowest 60
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
Network buffers: 30 lowest 30
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
emacps_handle_error: Receive buffer not available
emacps_handle_error: Receive buffer not available
pxEasyFit: ARP c0a81505ip -> c0a8150aip
emacps_handle_error: Receive buffer not available
Network buffers: 26 lowest 26
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
emacps_handle_error: Receive buffer not available
Network buffers: 24 lowest 24
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a8150aip
Network buffers: 22 lowest 22
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a8150aip end-point c0a8150aip
pxEasyFit: ARP c0a81505ip -> c0a81501ip
pxEasyFit: ARP c0a81505ip -> c0a81501ip
pxEasyFit: ARP c0a81505ip -> c0a81501ip
Network buffers: 9 lowest 9
ipARP_REQUEST from c0a81505ip to c0a81501ip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a81501ip end-point c0a8150aip
ipARP_REQUEST from c0a81505ip to c0a81501ip end-point c0a8150aip
emacps_send_message: Time-out waiting for TX buffer

@tony-josi-aws

Since the major difference between both allocation schemes is that the buffer allocation scheme 1 uses static memory, I would start checking where the ucNetworkPackets/pucNetworkPackets gets allocated and if it’s aligning with the SMP/HW configuration.

OK this comment is making me think that the problem might be the BufferAllocation1 is expecting to use uncached memory and maybe that is conflicting with the SMP cache coherent memory. I’m hardly an expert on this topic but I’ll see if I can investigate the ARM memory settings.