Zynq driver: avoid race conditions #1286
Merged
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.