Hi Dirk,
> Analyzing this we found that in sci_dma_rx_timer_fn() s->chan_rx is NULL.
Again, good catch. Thank you! Here is the outcome of my first debugging
session...
> Is there any chance that there is a race condition where the timer function
> sci_dma_rx_timer_fn() is called while s->chan_rx is invalidated, already.
> E.g. via sci_dma_rx_chan_invalidate()/sci_dma_rx_release()? Or anything
> else?
Only 'sci_dma_rx_chan_invalidate' clears s->chan_rx. I think these paths
involving 'sci_dma_rx_chan_invalidate' are OK:
sci_dma_rx_chan_invalidate <- sci_dma_rx_release <- sci_free_dma ...
A) <- sci_startup (no issue because interrupts could not be requested
and RX DMA is started in an interrupt)
B) <- sci_shutdown (no issue because 'hrtimer_cancel' has been called
before freeing DMA)
This path also seems ok:
sci_dma_rx_chan_invalidate <- sci_dma_rx_submit (error path)
<- sci_rx_interrupt (no issue because timer is started after
'sci_dma_rx_submit')
This path looks problematic:
sci_dma_rx_chan_invalidate <- sci_dma_rx_complete (error path)
The timer is started before DMA is set up. In the unlikely event of the
DMA setup failing, s->chan_rx will be cleared while the timer has
already been started. This is in deed a very rare condition.
The problem is that I cannot trigger the code patch so far. It is easy
to force 'sci_dma_rx_complete' to bail out but, so far, I couldn't get
it called.
Nonetheless, given this broken error path, I suggest two fixes which
I'll send out as RFC in some minutes.
All the best,
Wolfram
Attachment:
signature.asc
Description: PGP signature
