On 12/23/20 5:31 AM, Bert Schiettecatte wrote:
Hi all,
I have a rk3288 board I am working with, it has two ADCs and one DAC.
The ADCs are connected via an FPGA to the rk3288. The DAC is directly
connected to the I2S port of the rk3288. The rk3288 generates the
master clock. I am using buildroot and busybox and kernel 5.9.12
(stable).
I have a driver which receives the ADC data from the FPGA via SDIO.
When I run speaker-test in the background and use arecord to record
simultaneously in the foreground, both arecord and speaker-test seem
to lock up. When I run speaker-test alone I do not have a problem. The
playback device uses the rockchip_i2s.c driver while the capture
device uses my SDIO driver.
My driver based on dw_mmc.c calls snd_pcm_period_elapsed() for each
buffer of frames that is ready. I can see that this is being called
for a while when I start arecord in the foreground, until the lockup
occurs. The moment I start arecord, the console output from
speaker-test stops, so it's locked up by starting arecord.
Are these implemented as two separate sound cards? If so I don't see how
they could interfere with each other. There should not be any shared
resources or locks between them at least on the ALSA side.
Previously this was working fine on kernel 4.11. However, since I updated to
kernel 5.9.12 this no longer works. Has anything changed between 4.11
and 5.9.12 that could be the cause of the problem?
There are almost 300k commits between v4.11 and v5.9.12 one of them
surely could have added a new issue :)
If possible try to narrow this down a bit more, this will help to track
this down. If this is a more general issue it is quite likely that this
is a more recently introduced problem, otherwise others would have
already run into it. Maybe try one of the stable kernels like v5.4.
commands used for starting playback / trace capture and for recording -
./perf record -F 99 -g -e snd_pcm:* -e sched:sched_switch -e
sched:sched_wakeup -e irq:* speaker-test -D
hw:CARD=ak4458ak5558aud,DEV=0 -c8 -r192000 -FS32_LE -tsine &
arecord -Dhw:CARD=ak4458ak5558aud,DEV=1 -fS32_LE -c16 -r192000
/mnt/ramdisk/rec.wav
I enabled the kernel options as described at
https://www.kernel.org/doc/html/v5.9/sound/designs/tracepoints.html
and have used perf to record a trace, which can be access here -
https://kernel-debugging.s3-us-west-1.amazonaws.com/perf.data.script.211220202054.txt
(exported using "perf script")
The trace file shows "lockdep_recursion" at some point so I am
wondering if my problem has to do with a deadlock somehow being
caused.
lockdep_recursion is not even a function. I think this is just an
incorrectly resolved stack trace.
To check if there is a locking issue somewhere compile your kernel with
CONFIG_PROVE_LOCKING=y
Do both devices I2S and MMC use the same DMA? If so I could see things
going wrong there since that would be shared resources in the DMA
driver. If possible try to run the MMC driver without DMA and see what
happens.
- Lars
