Zynq driver: avoid race conditions#1286
Merged
Merged
Conversation
Contributor
Author
|
@tony-josi-aws and others: |
Member
|
@htibosch - I've started the checks! |
Contributor
Author
|
Thanks, the checks are now done. Is there currently anyone who could review/test this PR for Zynq-7000? |
Member
|
@htibosch I should be able to do that by early next week. |
Member
|
Thanks @htibosch for this PR, I was able to test this on the Zynq, looks good to me. |
tony-josi-aws
approved these changes
Sep 10, 2025
moninom1
approved these changes
Sep 10, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
A visitor on the FreeRTOS forum, trantam found that sometimes a TCP connection has non-active moments of 60 ms or longer. See this long conversation.
I did an earlier attempt in PR 1283, but it didn't solve all.
Changes how to handle notification value:
In the current driver, the EMAC task is woken up using a generic task notify:
vTaskNotifyGiveFromISR( xEMACTaskHandles[ xEMACIndex ], &xTaskWoken );and the notification value is stored in a separate variable.
In the new version, the notification value is stored in the task:
xTaskNotifyFromISR( xEMACTaskHandles[ xEMACIndex ], EMAC_IF_RX_EVENT, eSetBits, &( xTaskWoken ) );This guarantees 'atomic' updates of the notification value, both when setting or clearing.
Introduced a new mutex:
For received packets, there is only a single path: a RX interrupt setting
EMAC_IF_RX_EVENT, the EMAC task callsemacps_check_rx(), which sends the messages to a queue, owned by the IP-task.For transmissions, there are two paths, handled by these functions:
emacps_send_message()which sends packets.emacps_check_tx()which cleared used tx descriptors.Test Steps
Please refer to the forum post
Checklist:
Related Issue
Be careful when using Python socket for testing purposes, the behaviour may be unexpected. See forum post as well.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.