On 2016-03-04, John Ogness <john.ogn...@linutronix.de> wrote:
> Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite
> looping and kept a log of the number of loops that were executed. For
> my test I am regularly seeing 3000-3200 loops (with a max so far of
On 2016-03-03, John Ogness <john.ogn...@linutronix.de> wrote:
>>> Using next-20160302 I can very reliably hit this warning on an
>>> AM335x BeagleBone by playing a short audio file over USB-Audio:
>>>
>>> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE
&
but
100% of the hangs were in that exact situation. So I suspect a race
condition exists there.
> Does the issue happen in any previous kernel? Trying to think if there
> is any regression in next-20160302...
I will continue trying to reproduce the hang with newer kernels. I
haven't tried anyt
Hi Bin,
Using next-20160302 I can very reliably hit this warning on an AM335x
BeagleBone by playing a short audio file over USB-Audio:
$ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE
/usr/share/sounds/alsa/Front_Center.wav
$ aplay -l
List of PLAYBACK Hardware Devices
card 1: Audio [USB
channel is already gone. Thus, the next time txstate()
is called, there is a NULL pointer exception because the buffer is
mapped but no DMA channel is allocated.
This patch adds an extra call unmap_dma_buffer() before releasing the
channel.
Signed-off-by: John Ogness <john.ogn...@linutronix
