We are using SysLink in a way that I think is incompatible with how it is expected to be used and are seeking guidance for options to fix this.
Here’s what we are doing.
On the ARM core in Linux we have a tunnel network driver that uses SysLink to provide network packets to the DSP. The DSP then tunnels these over a serial link. The segregation is such because the DSP is in control of the serial port – it sends its own data across it and also the network data received from the ARM over SysLink.
This works OK for UDP communications. But TCP communications fail. We’ve isolated the failure to a TCP retransmission by the Linux network stack when it has a timer interrupt fire. The timer interrupt is atomic context, and the network stack code -- eventually -- calls our driver to retransmit the packet which calls into SysLink which needs to allocate some memory so it blocks on a mutex. The blocking on the mutex causes scheduling, which causes Linux to crash because scheduling is not supposed to happen while the kernel is atomic.
Is it possible to use SysLink in such a scenario? If so, how? I am not aware of a way to prevent scheduling that won't have other disatrous effects.
