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.2112202... (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